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 Implicit Grant Type.

Diagramme illustrant le flux Implicit Grant Type.

Dans ce flux OAuth :

  1. Par exemple, une application personnalisée 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 autorisé, l'utilisateur est redirigé vers une URL qui contient 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 Disponible
Requiert l'authentification client Non
Le client doit connaître les informations d'identification utilisateur Non
Interaction utilisateur via navigateur Oui
Peut utiliser un fournisseur d'identités externe pour l'authentification Oui
Le jeton d'actualisation est 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é 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é :

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

  • Sélectionnez le type d'octroi Implicite. Ce type d'application ne peut pas conserver de clé secrète et s'exécute sur un navigateur Web ou un appareil mobile non authentifié.

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, demandant 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.

    Exemple de demande avec mTLS

    Pour savoir comment obtenir le fichier secureDomainURL, reportez-vous à Types d'octroi d'accès.

    curl -v \
--cert cert.crt \
--key key.key \
--cacert ca.crt \
--location '<secureDomainURL>/oauth2/v1/token' \
--header 'Authorization: Basic <base64Encoded clientid:secret>'
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'grant_type=client_credentials' \
--data-urlencode 'client_id=<client-id>' \
--data-urlencode 'scope=urn:opc:idm:_myscopes_'

  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 lui permettant d'autoriser le partage d'informations.

  4. Une fois l'utilisateur 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é contenant toutes les portées applicables en fonction des privilèges représentés par les rôles d'application accordés à l'application client requérante et de 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.