Documentation sur Oracle Cloud Infrastructure

Type de droit implicite

Utilisez ce type d'autorisation lorsque l'application personnalisée ne peut pas garder les données d'identification du client confidentielles 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 illustrant 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 mis 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 cela est 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, par exemple une liste d'utilisateurs.

Fonction Disponibles
Nécessite l'authentification client Nombre
Requiert que le client connaisse les données d'identification de l'utilisateur Nombre
Interaction avec l'utilisateur final à partir d'un navigateur Oui
Peut utiliser un fournisseur d'identités externe pour l'authentification Oui
Le jeton d'actualisation est autorisé Nombre
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 des applications mises en oeuvre dans un navigateur Web à l'aide d'un langage de script tel que JavaScript ou mis 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 l'autorisation d'application côté client dans la console du domaine d'identité :

  • Spécifiez 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 une clé secrète et s'exécute sur un navigateur Web non authentifié ou un appareil mobile.

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 touche un bouton de connexion sur son appareil, demandant 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 au lieu du 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.