Documentation Oracle Cloud Infrastructure

Type d'octroi implicite

Utilisez ce type d'octroi lorsque l'application personnalisée ne peut pas garder les informations d'identification client confidentielles et reçoit un jeton d'accès directement à partir d'une demande d'autorisation plutôt que via un code d'autorisation intermédiaire.

Le diagramme suivant présente le flux de type d'octroi implicite.

Diagramme illustrant le flux de type d'octroi implicite.

Dans ce flux OAuth :

  1. Une application personnalisée, par exemple, est implémentée dans une application côté client à l'aide d'un langage de script tel que JavaScript ou implémentée pour un appareil mobile. L'utilisateur demande l'authentification et l'autorisation via l'application.

  2. L'application client invite l'utilisateur à fournir ses informations d'identification.

  3. L'utilisateur saisit ses informations d'identification.

  4. Si cette option est autorisée, l'utilisateur est redirigé vers une URL contenant le jeton d'accès dans un fragment d'URL.

  5. L'application extrait le jeton d'accès à partir de l'URL.

  6. L'application utilise le jeton d'accès dans une demande de ressources protégées, telle qu'une liste d'utilisateurs.

Fonction Disponibles
Nécessite une authentification client Non
Le client doit connaître les informations d'identification utilisateur Non
Interaction de l'utilisateur final basée sur un navigateur Oui
Peut utiliser un fournisseur d'identités externe pour l'authentification Oui
Jeton d'actualisation autorisé Non
Le jeton d'accès se trouve dans le contexte de l'utilisateur final Oui

Reportez-vous à un exemple de flux d'autorisation de type d'octroi implicite.

Exemple de flux d'autorisation de type d'octroi implicite

Cet exemple d'autorisation de type d'octroi implicite décrit le flux d'autorisation pour les applications implémentées dans un navigateur Web à l'aide d'un langage de script tel que JavaScript ou implémentées sur un appareil mobile. Un jeton d'accès est renvoyé au client via un réacheminement de navigateur en réponse à la demande d'autorisation du propriétaire de la ressource (plutôt qu'un code d'autorisation intermédiaire).

Lorsque vous créez une application pour l'autorisation d'application côté client dans la console du domaine d'identité, procédez comme suit :

  • Indiquez qu'il s'agit d'un type d'application mobile.

  • Sélectionnez Implicite comme type d'octroi. Ce type d'application ne peut pas garder un secret et s'exécute sur un navigateur Web non authentifié ou un appareil mobile.

Pour plus d'informations sur le type d'octroi implicite et un diagramme de flux d'autorisation, reportez-vous à Type d'octroi implicite.

Etapes de traitement

  1. Un utilisateur clique sur un lien de connexion dans son application de navigateur ou appuie sur un bouton de connexion sur son appareil pour demander l'accès aux ressources protégées à partir d'une application client.

  2. Le client redirige le navigateur vers le serveur d'autorisation OAuth avec une demande d'autorisation.

    L'URL de connexion contient des paramètres de requête qui indiquent le type d'accès demandé :

    Exemple de demande https://acme.identity.us.oraclecloud.com/oauth2/v1/authorize?client_id=<client-id>&response_type=token&redirect_uri=<client-redirect-uri>&scope=<scope>&nonce=<nonce-value>
    Remarque

    Une valeur nonce est une chaîne aléatoire cryptographiquement forte que vous utilisez pour empêcher la réutilisation des réponses interceptées.

  3. Si l'utilisateur n'est pas déjà connecté, le serveur d'autorisation OAuth demande à l'utilisateur de s'authentifier. Le serveur d'autorisation OAuth authentifie l'utilisateur et fournit une page de consentement permettant à l'utilisateur d'autoriser le partage d'informations.

  4. Une fois que l'utilisateur l'a autorisé, le serveur d'autorisation OAuth redirige le navigateur vers le site demandeur avec un jeton d'accès.
    Remarque

    Si l'utilisateur ne s'authentifie pas, une erreur est renvoyée plutôt que le jeton d'accès.

  5. Le jeton d'accès est renvoyé et contient toutes les portées applicables en fonction des privilèges représentés par les rôles d'application accordés à l'application client à l'origine de la demande et à l'utilisateur spécifié par la demande du client (le cas échéant).

  6. Le site demandeur utilise le jeton d'accès dans un appel d'API pour obtenir des données protégées.