Utilisation de OAuth 2 pour accéder à l'API REST
L'API REST des domaines d'identité prend en charge les points d'extrémité conformes à SCIM 2.0 avec des schémas de base SCIM 2.0 et des extensions de schéma Oracle pour gérer par programmation les utilisateurs, les groupes, les applications et les fonctions d'identité, telles que la gestion des mots de passe et les tâches d'administration. Pour effectuer des appels d'API REST vers votre domaine d'identité, vous devez disposer d'un jeton d'accès OAuth2 à utiliser pour l'autorisation. Le jeton d'accès fournit une session (avec portée et expiration), que votre application client peut utiliser pour effectuer des tâches dans un domaine d'identité.
Le diagramme de séquence suivant illustre un exemple de base du flux d'autorisation OAuth 2.0 pour accéder à l'API REST des domaines d'identité.

Utilisez des paramètres OAuth 2.0 spécifiques lors de l'utilisation d'un domaine d'identité. Le tableau suivant décrit les paramètres les plus courants.
Paramètre | Valeur | Commentaires |
---|---|---|
En-tête d'autorisation |
<base64_clientid_secret> de base |
Utilisé par le client comme modèle d'authentification de base pour transmettre le jeton d'accès dans un en-tête. La valeur du jeton d'accès doit être une valeur encodée en UTF-8 base64 de l'ID client et de la clé secrète client concaténés à l'aide d'un deux-points comme séparateur, par exemple, clientID:clientSecret. |
ID client |
<client_id> |
Obligatoire. "Clé d'API" unique générée lors de l'enregistrement de votre application dans la console du domaine d'identité. |
Secret de client |
<client_secret> |
Obligatoire. Clé privée similaire à un mot de passe généré lors de l'enregistrement de votre application dans la console du domaine d'identité. Ne partagez pas cette valeur. |
URL de jeton d'accès |
/oauth2/v1/token |
Point d'extrémité utilisé pour obtenir un jeton d'accès à partir du domaine d'identité. |
URL Aut |
/oauth2/v1/authorize |
Point d'extrémité utilisé pour obtenir un code d'autorisation à partir des domaines d'identité, puis utilisé lors d'un flux OAuth à 3 branches. |
Type d'autorisation |
client_credentials |
Obligatoire. Cela signifie que l'API REST appelée appartient à l'application client. |
Portée (obligatoire) |
urne:opc:idm :__myscopes__ |
Cette portée retourne tous les droits accordés à votre application, d'autres étendues peuvent être utilisées pour obtenir des droits spécifiques, si nécessaire. |
Étape 1 : Enregistrer une application confidentielle dans des domaines d'identité à l'aide de la console
Lorsque vous enregistrez une application confidentielle dans la console du domaine d'identité, vous obtenez certains des paramètres clés dont vous avez besoin pour utiliser OAuth 2.0 : ID client, clé secrète client et étendues. OAuth 2.0 est une norme pour la mise en oeuvre de l'autorisation déléguée, et l'autorisation est basée sur le jeton d'accès requis pour accéder à une ressource. Le jeton d'accès peut être émis pour une portée donnée, qui définit ce que le jeton d'accès peut faire et les ressources auxquelles il peut accéder. Lorsque vous enregistrez une application Web dans un domaine d'identité, vous ajoutez des portées. Dans l'exemple suivant, les portées requises pour demander des recherches d'utilisateur, des modifications, des créations et des suppressions sont ajoutées. Mais, si vous deviez faire d'autres choses, par exemple, gérer les événements de vérification, cela nécessiterait d'autres étendues.
Pour créer et enregistrer une application confidentielle, accédez à la console OCI, puis procédez comme suit :
- Ouvrez le menu de navigation et sélectionnez Identité et sécurité. Sous Identité, sélectionnez Domaines.
- Cliquez sur le nom du domaine d'identité dans lequel vous voulez travailler. Vous devrez peut-être modifier le compartiment pour trouver le domaine souhaité. Cliquez ensuite sur Applications intégrées.
- Sélectionnez Ajouter une application.
- Dans la boîte de dialogue Ajouter une application, sélectionnez Application confidentielle, puis Lancer le flux de travail.
- Dans la page Ajouter les détails de l'application, entrez un nom d'application et une description, puis sélectionnez Suivant.
- Dans la page Configurer OAuth, sous Configuration du client, sélectionnez Configuration de cette application comme client maintenant.
- Sous Autorisation, sélectionnez uniquement Données d'identification du client comme type de droit autorisé.
- Au bas de la page, sélectionnez Ajouter des rôles d'application, puis Ajouter des rôles.
- Dans le panneau Ajouter des rôles d'application, sélectionnez Administrateur de domaine d'identité, puis Ajouter.
- Sélectionnez Suivant, puis Terminer.
- Dans la page des détails de l'application, faites défiler l'affichage vers le bas jusqu'à Informations générales. Copiez l'ID client et la clé secrète client, puis stockez-les dans un emplacement sécurisé.
- Une fois l'application créée, sélectionnez Activer.
Étape 2 : Base64 Encoder l'ID client et la clé secrète client
Avant l'encodage base64, l'URL encode individuellement l'ID client et la clé secrète client. Si votre ID client et votre clé secrète client ne contiennent pas de caractères spéciaux, vous n'êtes pas obligé de les encoder par URL en premier. Cependant, en tant que meilleure pratique, nous le recommandons vivement.
Windows
-
Lancez le Bloc-notes, puis collez l'ID client et la clé secrète client dans le Bloc-notes.
-
Placez l'ID client et la clé secrète client sur la même ligne et insérez un deux-points entre eux :
clientid:clientsecret
Note
Assurez-vous qu'aucun espace n'est l'attribut clientid:clientsecret. -
Enregistrez le fichier dans
C:\temp
et nommez-leappCreds.txt.
-
Dans l'Explorateur Windows, cliquez avec le bouton droit de la souris sur
C:\temp
, puis sélectionnez Invite CMD ici dans le menu contextuel. -
Entrez la commande suivante pour encoder l'ID client et la clé secrète client :
certutil -encode appCreds.txt appbase64Creds.txt
-
Dans le Bloc-notes, ouvrez
C:\temp\appbase64Creds.txt
, copiez son contenu, puis fermez le fichier.Note
Pour des raisons de sécurité, supprimez les fichiersappCreds.txt
etappbase64Creds.txt
une fois que vous avez terminé.
Mac et Linux
-
Lancez votre utilitaire de note préféré (par exemple, Mac Notes, Gedit Linux ou Vi), puis collez l'ID client et la clé secrète client dans l'utilitaire de note.
Placez l'ID client et la clé secrète client sur la même ligne et insérez un deux-points entre eux :
clientid:clientsecret.
Noteénoncé.
Assurez-vous qu'il n'y a pas d'espace dans clientid:clientsecret.-
Copiez la ligne
clientid:clientsecret
. -
Lancez un terminal et entrez la commande suivante, en remplaçant
clientid:clientsecret
par la valeur que vous avez copiée dans le presse-papiers.echo -n "clientid:clientsecret" | base64 -w 0
Note
Pour Linux, ajoutez-w 0
à la commande pour supprimer les sauts de ligne. -
Copiez la valeur retournée.Note
Si la valeur retournée est divisée en plusieurs lignes, retournez à l'éditeur de texte et assurez-vous que les résultats complets se trouvent sur une seule ligne sans encapsulation de texte.
Étape 3 : Obtenir un jeton d'accès
L'étape suivante de ce processus consiste à demander le jeton d'accès.
-
Lancez une invite de commande.
-
Entrez la commande cURL ci-dessous, en remplaçant le texte entre crochets ( < > ) par les valeurs appropriées :
curl -i -H "Authorization: Basic <base64encoded clientid:secret>" -H "Content-Type: application/x-www-form-urlencoded;charset=UTF-8" --request POST https://<domainURL>/oauth2/v1/token -d "grant_type=client_credentials&scope=urn:opc:idm:__myscopes__"
Note
Si vous utilisez un système d'exploitation UNIX, vous pouvez ajouter| awk -F"\"" '{print $4}'
à la fin de la commande cURL pour analyser uniquement le jeton Bearer. N'oubliez pas que l'expiration par défaut du jeton est de 3600 secondes à partir du moment de la demande.Note
Facultativement, exécutez la commande cURL suivante pour que la valeur du jeton d'accès soit accessible au moyen d'une variable UNIX nomméeAccessTokenValue
dans votre environnement :
Vous pouvez ensuite exécuter la commandeexport AccessTokenValue=`curl -i -H "Authorization: Basic <base64encoded clientid:secret>" -H "Content-Type: application/x-www-form-urlencoded;charset=UTF-8" --request POST https://<domainURL>/oauth2/v1/token -d "grant_type=client_credentials&scope=urn:opc:idm:__myscopes__" | awk -F"\"" '{print $4}' | tail -n +16`
echo $AccessTokenValue
pour obtenir la valeur du jeton d'accès.Texte entre crochets Valeur base64encoded clientid:secret Remplacez par les données d'identification encodées que vous avez générées dans la section Base64 Encoder l'ID client et la clé secrète client. Assurez-vous qu'il n'y a aucun espace dans les données d'identification clientid:clientsecret. IDCS_Service_Instance Remplacer par l'URL de votre domaine d'identité (par exemple, https://<domainURL>/).
Note
La portéeurn:opc:idm:__myscopes__
de la commande est utilisée en tant que marqueur par les clients du domaine d'identité demandant des jetons d'accès au serveur d'autorisations OAuth. Les jetons d'accès retournés contiennent toutes les étendues de domaines d'identité applicables en fonction des privilèges représentés par les rôles d'administrateur de domaines d'identité accordés au client demandeur et à l'utilisateur spécifié par la demande du client (le cas échéant). Cette étendue n'est octroyée directement à aucun rôle d'administrateur de domaines d'identité. -
Copiez la valeur
access_token
de la réponse. Assurez-vous de copier uniquement le jeton réel, qui est la valeuraccess_token
entre guillemets :Status: 200 "access_token":"eyJ4NXQiOiI4Wk. . ." "token":"Bearer", "expires_in":3600
Note
La réponse inclut le paramètreexpires_in: 3600
. Cela signifie que votre jeton n'est plus valide après une heure à partir du moment où vous le générez. Après une heure, vous devez actualiser le jeton ou obtenir un nouveau jeton d'accès. Pour actualiser le jeton, entrez la commande cURL ci-dessous, en remplaçant le texte entre crochets ( < > ) par les valeurs appropriées :curl -i -H "Authorization: Basic <base64 encoded client ID and secret>" -H "Content-Type: application/x-www-form-urlencoded;charset=UTF-8" --request POST https://<domainURL>/oauth2/v1/token -d "grant_type=refresh_token&refresh_token=<token_value>"
Étape 4 : Faire une demande REST à l'environnement
Après avoir obtenu le jeton d'accès OAuth 2.0, vous pouvez utiliser le jeton dans une commande cURL pour envoyer une demande REST à l'API REST des domaines d'identité. La commande suivante retourne une liste d'utilisateurs dans un domaine d'identité.
curl -X GET
-H "Content-Type:application/scim+json"
-H "Authorization: Bearer <access_token>"
https://<domainURL>/admin/v1/Users
Élément | Valeur |
---|---|
Méthode | -X OBTENIR |
En-tête de type de contenu | -H "Content-Type:application/scim-json" |
En-tête d'autorisation | -H "Autorisation : Porteur <access_token>" |
Protocole HTTP | HTTP ou HTTPS (HTTP est recommandé) |
Domaine d'identité | URL du domaine d'identité (par exemple, https://<domainURL>). |
Point d'extrémité REST des domaines d'identité | /admin/v1/Users |
Exemple de sortie JSON à partir de l'API REST des domaines d'identité
À l'étape précédente, la demande REST envoyée à l'aide de cURL a retourné une réponse au format JSON. JSON est une norme ouverte qui peut être formatée ou analysée selon vos besoins, comme l'obtention d'attributs spécifiques requis par votre application.
{
"schemas": [
"urn:scim:api:messages:2.0:ListResponse"
],
"totalResults": 1,
"Resources": [
{
"displayName": "admin opc",
"name": {
"givenName": "admin",
"formatted": "admin opc",
"familyName": "opc"
},
"urn:ietf:params:scim:schemas:oracle:idcs:extension:userState:User": {
"locked": {
"on": false
}
},
"userName": "admin@example.com",
"id": "d252a54d83c344eb8f59f7053a0562ce",
"urn:ietf:params:scim:schemas:oracle:idcs:extension:user:User": {
"isFederatedUser": false
},
"active": true,
"nickName": "TAS_TENANT_ADMIN_USER",
"emails": [
{
"verified": false,
"value": "admin@example.com",
"type": "work",
"primary": true
},
{
"verified": false,
"value": "admin@example.com",
"primary": false,
"type": "recovery"
}
],
"schemas": [
"urn:ietf:params:scim:schemas:oracle:idcs:extension:user:User",
"urn:ietf:params:scim:schemas:oracle:idcs:extension:userState:User",
"urn:ietf:params:scim:schemas:core:2.0:User"
],
"meta": {
"resourceType": "User",
"created": "2022-07-22T18:11:08Z",
"lastModified": "2022-07-25T21:19:28Z",
"location": "https://<domainURL>admin/v1/Users/d252a54d83c344eb8f59f7053a0562ce"
},
"idcsLastModifiedBy": {
"value": "idcssso",
"$ref": "https://<domainURL>admin/v1/Apps/idcssso",
"type": "App",
"display": "idcssso"
}
}
],
"startIndex": 1,
"itemsPerPage": 50
}