Documentation sur Oracle Cloud Infrastructure

Type de droit implicite

Utilisez ce type d'autorisation lorsque l'application personnalisée ne peut pas conserver la confidentialité des données d'identification du client et reçoit un jeton d'accès directement à partir d'une demande d'autorisation, plutôt qu'au moyen d'un code d'autorisation intermédiaire.

Le diagramme suivant présente le flux Implicit Grant Type.

Diagramme qui illustre le flux de type de subvention implicite.

Dans ce flux OAuth :

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

  2. L'application client invite l'utilisateur à fournir ses données d'identification.

  3. L'utilisateur entre ses données 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 de l'URL.

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

Fonction Disponible
Nécessite l'authentification client Non
Nécessite que le client connaisse les données d'identification de l'utilisateur Non
Interaction de l'utilisateur final basée sur le navigateur Oui
Peut utiliser un fournisseur d'identités externe pour l'authentification Oui
Actualiser le jeton est autorisé Non
Le jeton d'accès est dans le contexte de l'utilisateur final Oui

Voir un exemple de flux d'autorisation de type d'octroi implicite.

Exemple de flux d'autorisation de type de subvention implicite

Cet exemple d'autorisation de type d'autorisation implicite décrit le flux d'autorisation pour les applications mises en oeuvre dans un navigateur Web à l'aide d'un langage de script tel que JavaScript ou mises en oeuvre sur un appareil mobile. Un jeton d'accès est retourné au client au moyen d'une redirection de navigateur en réponse à la demande d'autorisation du responsable de la ressource (plutôt qu'un code d'autorisation intermédiaire).

Lorsque vous créez une application pour une 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 Implicite comme type d'autorisation. 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é.

Voir Type d'autorisation implicite pour plus d'informations sur le type d'autorisation implicite et un diagramme de flux d'autorisation.

Traitement des étapes

  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 à des 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 d'interrogation 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>
    Note

    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 utilisant mTLS

    Pour savoir comment obtenir secureDomainURL, voir Types d'autorisation 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 invite l'utilisateur à 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 l'utilisateur autorisé, le serveur d'autorisation OAuth redirige le navigateur vers le site demandeur avec un jeton d'accès.
    Note

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

  5. Le jeton d'accès est retourné contenant toutes les étendues 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.