Portées
A l'aide du paramètre de portée, le jeton d'accès peut accorder différents niveaux d'accès à plusieurs API de domaine d'identité IAM.
Les portées permettent de définir plus précisément un ensemble de ressources et d'opérations autorisées par un jeton d'accès. Les portées représentent une intention. Lorsqu'un client demande un jeton d'accès, les étendues demandées indiquent le type de fonctionnalité à utiliser lors de la présentation du jeton d'accès.
En outre, différents types d'application utilisent différents octrois de jeton d'accès. Les applications sécurisées (telles que les services back-end) peuvent demander des jetons d'accès directement au nom des utilisateurs. Les applications Web doivent généralement d'abord valider l'identité de l'utilisateur et éventuellement obtenir son consentement.
Utilisez la portée urn:opc:idm:__myscopes__
lorsque vous devez obtenir un jeton d'accès contenant toutes les portées de domaine d'identité autorisées. Les jetons d'accès qui contiennent toutes les portées de domaine d'identité applicables sont renvoyés en fonction des privilèges représentés par les rôles d'application de domaine d'identité accordés au client demandeur et à l'utilisateur spécifié par la demande du client (le cas échéant). Cette portée n'est octroyée directement à aucun rôle d'administrateur de domaine d'identité.
Utilisez la portée urn:opc:idm:role.<r_name>
(par exemple, urn:opc:idm:role.User%20Administrator)
lorsque vous devez obtenir un jeton d'accès contenant les portées applicables d'un rôle spécifique, à condition que le client et l'utilisateur disposent du rôle spécifique. Par exemple, pour demander un jeton d'accès avec une portée basée sur les rôles d'administrateur utilisateur et d'administrateur d'application :
Exemple de demande
curl -i
-H 'Content-Type: application/x-www-form-urlencoded;charset=UTF-8'
--request POST https://<domainURL>/oauth2/v1/token
-d 'grant_type=password&username=<user-name>&password=<example-password>&client_id=<client-id>&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer&client_assertion=<client-assertion>&scope=urn:opc:idm:role.User%2520Administrator urn:opc:idm:role.Application%2520Administrator'
Le jeton d'accès généré contiendrait les portées applicables à l'administrateur utilisateur et à l'administrateur de l'application tant que ces rôles sont accordés au client et à l'utilisateur. Par exemple, un client dispose de Role1, Role2 et Role3. Un utilisateur dispose des rôles Role1, Role2 et 4. Les portées incluses dans la demande pour le jeton d'accès sont Role1 et Role3. Le jeton d'accès généré contient uniquement les portées pour Role1.
Les demandes de portée peuvent avoir plusieurs étendues séparées par des espaces. Si un nom de portée contient un espace, le serveur ne peut pas déterminer la limite de portée correcte. Cela peut se produire lorsqu'un nom de rôle est utilisé dans la portée. Dans l'exemple de demande, les rôles "user administrator" et "application administrator" ont des espaces codés en URL : scope=urn:opc:idm:role.User%2520Administrator urn:opc:idm:role.Application%2520Administrator.
Pour éviter les problèmes d'espace dans les noms de rôle, vous devez encoder deux fois les noms de rôle à l'aide de l'encodage d'URL :
Exemple de code Java
String scope = "scope=urn:opc:idm:role." + URLEncoder.encode(URLEncoder.encode("User Administrator", "UTF-8"), "UTF-8");
scope = scope + " urn:opc:idm:role." + URLEncoder.encode(URLEncoder.encode("Application Administrator", "UTF-8"), "UTF-8");
Aucune portée définie pour une application
/oauth2/v1/authorize
:scope=openid
: le jeton d'accès obtenu peut être utilisé avec/oauth2/c1/userinfo
, qui fournit le minimum d'informations utilisateur.scope=openid approles groups
: le jeton d'accès obtenu peut être utilisé avec/oauth2/v1/userinfo
pour obtenir les rôles et les groupes de l'utilisateur.
Utilisation des portées de confiance
Les portées de confiance définissent la façon dont un client OAuth accède aux ressources. Les portées de confiance permettent à une application client sécurisée ou confidentielle d'acquérir un jeton d'accès qui donne accès à l'une des ressources d'un domaine d'identité (Account
), à d'autres ressources basées sur des balises définies (Tags
), ou uniquement aux services pour lesquels il existe une association explicite entre le client et le service (Explicit
).
L'option permettant de définir le paramètre
trustScope
n'est disponible que pour les applications client sécurisées et confidentielles. L'option n'est pas disponible pour les applications client publiques.The
trustScope
attributes of Account,
Tags
, and Explicit
are named All (for Account
), Tagged (for Tags
), and Specific (for Explicit
) in the identity domain Console.-
Utilisez uniquement la portée
urn:opc:resource:consumer::all
dans la demande. Une erreur de portée non valide est renvoyée si vous tentez d'inclure à la fois la portéeurn:opc:resource:consumer::all
et une autre portée dans la même demande, par exempleurn:opc:idm:__myscopes__.
-
La demande d'un jeton d'accès à l'aide de la portée
urn:opc:resource:consumer::all
ne renvoie pas de jeton d'accès permettant d'accéder aux API d'administration des domaines d'identité. Vous devez continuer à utiliser la portée :urn:opc:idm:__myscopes__
pour accéder aux API d'administration. Reportez-vous à Portées. -
Le champ d'application demandé par l'application Client doit toujours exister et correspondre, directement ou hiérarchiquement, aux champs d'application autorisés définis du client pour permettre à ce dernier d'accéder à la ressource.
-
La valeur
trustScope
deExplicit
est affectée par défaut aux applications client sécurisées et confidentielles et permet à votre application client d'acquérir un jeton d'accès avec des droits d'accès basés sur une association explicite entre le client et les services cible. Pour utiliser l'optionAll
ouTagged
, vous devez mettre à jour l'application client avec la valeurtrustScope
All
ouTags.
- Pour les demandes de jeton de propagation d'identité utilisant la portée
urn:opc:resource:consumer::all
, le jeton d'accès obtenu n'inclut pas la portéeurn:opc:resource:consumer::all
.
Les liens suivants fournissent plus d'informations sur chaque trustScope
disponible :
Utilisation du périmètre de confiance du compte
La portée d'approbation Account
permet à une application client sécurisée ou confidentielle d'obtenir un jeton d'accès qui donne accès à l'un des services qui se trouvent dans le même domaine d'identité sans nécessiter d'association explicite avec les services cible.
L'option permettant de définir le paramètre
trustScope
n'est disponible que pour les applications client sécurisées et confidentielles. L'option n'est pas disponible pour les applications client publiques.Pour utiliser la portée d'approbation Account
, procédez comme suit :
-
Affectez la valeur de
Account
au paramètretrustScope
pour l'application client sécurisée appropriée.Remarque
L'attributtrustScope
deAccount
est nommé Tout dans la console du domaine d'identité. -
Demandez un jeton d'accès à l'aide du client sécurisé ou confidentiel, et demandez la portée
urn:opc:resource:consumer::all.
Le jeton d'accès dans la réponse contient l'audienceurn:opc:resource:scope:account
et la portéeurn:opc:resource:consumer::all
, qui donne accès à l'un des services qui se trouvent dans le même domaine sans nécessiter d'association explicite avec les services cible.
La portée demandée doit toujours exister et correspondre, directement ou hiérarchiquement, aux portées autorisées définies du client pour permettre à ce dernier d'accéder à la ressource.
Utiliser des portées de niveau fin
urn:opc:resource:consumer::all
, vous pouvez également indiquer les portées détaillées suivantes :urn:opc:resource:consumer:paas::read
urn:opc:resource:consumer:paas:stack::all
urn:opc:resource:consumer:paas:analytics::read
urn:opc:resource:consumer:paas:analytics::read
dans sa demande pour accéder à une ressource. Si la portée correspond directement à une portée autorisée définie, dans le jeton d'accès renvoyé, le public est urn:opc:resource:scope:account
et la portée est urn:opc:resource:consumer:paas:analytics::read.
Si la portée autorisée définie par le client est urn:opc:resource:consumer:paas::read
, l'application client est autorisée à accéder à la ressource de manière hiérarchique si le client demande l'une des portées suivantes : urn:opc:resource:consumer:paas::read
ou urn:opc:resource:consumer:paas:analytics::read.
Toutefois, si la portée demandée est urn:opc:resource:consumer:paas:analytics::write,
, le client n'est pas autorisé à accéder à la ressource, car il ne s'agit pas de l'une des portées autorisées définies par l'application client.
Exemples de demandes et de réponses
Les exemples suivants présentent des exemples de demande et de réponse pour les informations d'identification client et les flux d'octroi de propriétaire de ressource.
Exemple de demande de flux d'informations d'identification client
curl -i
-H 'Authorization: Basic TXlUZXN0U2VydmljZV9BUFBJRDoxMGE2ODAwMC03YTYzLTQxNDItODE0Ny03MGNmMGJhMDFkYjg='
-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:resource:consumer::all' -k
Exemple de réponse
{
"access_token":"eyJ4NX....Zh3ieBlQ",
"token_type":"Bearer",
"expires_in":3600
}
Le jeton d'accès contient l'audience
urn:opc:resource:scope:account
et la portée urn:opc:resource:consumer::all.
Exemple de demande de flux de propriétaire de ressource
curl -i
-H 'Authorization: Basic TXlUZXN0U2VydmljZV9BUFBJRDoxMGE2ODAwMC03YTYzLTQxNDItODE0Ny03MGNmMGJhMDFkYjg='
-H 'Content-Type: application/x-www-form-urlencoded; charset=utf-8'
--request POST https://<domainURL>/oauth2/v1/token'
-d 'grant_type=password&scope=urn:opc:resource:consumer::all&username=admin@example.com&password=PasswordExample1'-k
Exemple de réponse
{
"access_token":"eyJ4NX...71aImeBsU",
"token_type":"Bearer",
"expires_in":3600
}
Exemples de demandes et de réponses utilisant une portée entièrement qualifiée
Les exemples suivants présentent des exemples de demande et de réponse utilisant une portée complète.
Exemple de demande
curl -i
-H 'Authorization: Basic TXlUZXN0U2VydmljZV9BUFBJRDoxMGE2ODAwMC03YTYzLTQxNDItODE0Ny03MGNmMGJhMDFkYjg='
-H 'Content-Type: application/x-www-form-urlencoded; charset=utf-8'
--request POST 'https://<domainURL>/oauth2/v1/token'
-d 'grant_type=client_credentials&scope=http://abccorp1.com/scope1'
Exemple de réponse
{
"access_token":"eyJ4NXzF.....rT5SH7sUw",
"token_type":"Bearer",
"expires_in":3600
}
Exemple de demande de flux de propriétaire de ressource incluant la demande d'un jeton d'actualisation
Afin de générer un jeton d'actualisation en plus du jeton d'accès, utilisez la portée urn:opc:resource:consumer::all offline_access
dans la demande.
curl -i
-H 'Authorization: Basic TXlUZXN0U2VydmljZV9BUFBJRDoxMGE2ODAwMC03YTYzLTQxNDItODE0Ny03MGNmMGJhMDFkYjg='
-H 'Content-Type: application/x-www-form-urlencoded; charset=utf-8'
--request POST https://<domainURL>/oauth2/v1/token'
-d 'grant_type=password&scope=urn:opc:resource:consumer::all offline_access&username=admin@example.com&password=PasswordExample1'-k
Exemple de réponse
{
"access_token":"eyJ4...pNYM0M",
"token_type":"Bearer",
"expires_in":3600,
"refresh_token":"AQIDBAUi....djF9NCA="
}
Utilisation de la portée sécurisée des balises
La portée d'approbation Tags
permet à une application client sécurisée ou confidentielle d'obtenir un jeton d'accès qui donne accès à d'autres ressources en fonction des balises définies.
L'option permettant de définir le paramètre
trustScope
n'est disponible que pour les applications client sécurisées et confidentielles. L'option n'est pas disponible pour les applications client publiques.Pour utiliser la portée d'approbation Tags
, procédez comme suit :
-
Affectez la valeur de
Tags
au paramètretrustScope
pour permettre à l'application client d'accéder à des balises d'autres applications.Remarque
L'attributtrustScope
deTags
est nommé Balisé dans la console du domaine d'identité. -
Définissez la paire
key:value
pour le paramètreAllowedTags
.Remarque
Ces étapes supposent que l'application de ressource appropriée a défini des paireskey:value
pour l'attributTags
et qu'au moins une pairekey:value
de la liste de l'attributallowedTags
de l'application client correspond à une pairekey:value
de l'attributTags
de l'application de ressource. -
Demandez un jeton d'accès à l'aide du client sécurisé ou confidentiel, et demandez la portée
urn:opc:resource:consumer::all.
Le jeton d'accès dans la réponse contient le publicurn:opc:resource:scope:tag=<base64 encoded JSON>
et la portéeurn:opc:resource:consumer::all
, qui donnent accès aux applications de ressource dont les balises correspondent aux balises autorisées spécifiées dans l'application client.
La portée demandée doit toujours exister et correspondre, directement ou hiérarchiquement, aux portées autorisées définies du client pour permettre à ce dernier d'accéder à la ressource.
Utiliser des portées de niveau fin
urn:opc:resource:consumer::all
, vous pouvez également indiquer les portées détaillées suivantes :urn:opc:resource:consumer:paas::read
urn:opc:resource:consumer:paas:stack::all
urn:opc:resource:consumer:paas:analytics::read
urn:opc:resource:consumer:paas:analytics::read
dans sa demande pour accéder à une ressource. Si la portée correspond directement à une portée autorisée définie, dans le jeton d'accès renvoyé, le public est urn:opc:resource:scope:tag=<base64 encoded JSON>
et la portée est urn:opc:resource:consumer:paas:analytics::read.
Si la portée autorisée définie par le client est urn:opc:resource:consumer:paas::read
, l'application client est autorisée à accéder à la ressource de manière hiérarchique si le client demande l'une des portées suivantes : urn:opc:resource:consumer:paas::read
ou urn:opc:resource:consumer:paas:analytics::read.
Toutefois, si la portée demandée est urn:opc:resource:consumer:paas:analytics::write,
, le client n'est pas autorisé à accéder à la ressource, car il ne s'agit pas de l'une des portées autorisées définies par l'application client.
Exemples de demandes et de réponses
Les exemples suivants présentent des exemples de demande et de réponse pour le flux d'informations d'identification client à l'aide de la portée urn:opc:resource:consumer::all
.
Exemple de demande
curl -i
-H 'Authorization: Basic MjA3Mz....zllNjI2'
-H 'Content-Type: application/x-www-form-urlencoded; charset=utf-8'
--request POST 'https://tenant101.idcs.internal.oracle.com:8943/oauth2/v1/token'
-d 'grant_type=client_credentials&scope=urn:opc:resource:consumer::all'
Exemple de réponse
{
"access_token""eyJ4NX....ZbDtAw",
"token_type":"Bearer", "expires_in":3600
}
Le jeton d'accès contient l'audience
urn:opc:resource:scope:tag=<base64 encoded JSON>
et la portée urn:opc:resource:consumer::all.
Voici un exemple d'audience décodée : aud:["urn:opc:resource:scope:tag=eyAidGFncyI6WyB7ICJrZXkiOiJjb2xvciIsInZhbHVlIjoiZ3JlZW4ifSAsICB7ICJrZXkiOiJjb2xvciIsInZhbHVlIjoiYmx1ZSJ9IF19"]
Les exemples suivants présentent des exemples de demande et de réponse pour le flux d'informations d'identification client à l'aide d'une portée complète.
Exemple de demande
curl -i
-H 'Authorization: Basic MzRjYz....Q3OWVk'
-H 'Content-Type: application/x-www-form-urlencoded; charset=utf-8'
--request POST 'https://<domainURL>/oauth2/v1/token'
-d 'grant_type=client_credentials&scope=http://abccorp1.com/scope1'
Exemple de réponse
{
"access_token""eyJ4NXzF.....rT5SH7sUw",
"token_type":"Bearer",
"expires_in":3600
}
Utiliser la portée de confiance explicite
La portée d'approbation Explicit
définit la portée d'approbation uniquement pour les services pour lesquels il existe une association explicite entre le client et le service cible.
L'option permettant de définir le paramètre
trustScope
n'est disponible que pour les applications client sécurisées et confidentielles. L'option n'est pas disponible pour les applications client publiques.Vous n'avez rien à faire pour utiliser la portée d'approbation Explicit
car il s'agit de la valeur par défaut affectée à l'application client sécurisée et confidentielle. Pour utiliser l'option Account
ou Tags
, vous devez mettre à jour l'application client avec la valeur trustScope
Account
ou Tags.
L'attribut
trustScope
de Explicit
est nommé Spécifique dans le domaine d'identité.Reportez-vous aux sections Using the Account Trust Scope et Using the Tags Trust Scope.
Exemples de demandes et de réponses
Les exemples de demande et de réponse présentent le flux d'informations d'identification client à l'aide d'une portée qualifiée complète.
Exemple de demande
curl -i
-H 'Authorization: Basic MzRjYz....Q3OWVk'
-H 'Content-Type: application/x-www-form-urlencoded; charset=utf-8'
--request POST 'https://<domainURL>/oauth2/v1/token'
-d 'grant_type=client_credentials&scope=http://abccorp1.com/scope1'
Exemple de réponse
{
"access_token""eyJ4NXzF.....rT5SH7sUw",
"token_type":"Bearer",
"expires_in":3600
}
Utilisation des portées de confiance explicites à partir de plusieurs ressources
La portée d'approbation Explicit
définit la portée d'approbation uniquement pour les services pour lesquels il existe une association explicite entre le client et le service cible. Vous pouvez spécifier plusieurs portées appartenant à différentes ressources dans une seule demande d'autorisation ou de jeton et obtenir plusieurs jetons d'accès en retour avec chacun d'eux contenant les portées pour chaque ressource.
- Vous devez indiquer la nouvelle portée définie,
urn:opc:resource:multiresourcescope
, dans la demande d'autorisation ou de jeton. Les demandes de jeton échoueront si plusieurs portées appartenant à différentes ressources sont spécifiées sans cette portée. - Le client OAuth doit pouvoir analyser la réponse de jeton qui inclut plusieurs jetons d'accès et utiliser chaque jeton pour accéder à chaque service de ressource.
Vous pouvez utiliser cette fonctionnalité avec tous les types d'octroi, à l'exception du flux implicite. Reportez-vous à la section Implicit Grant Type.
Pour plus d'informations sur les portées de confiance explicites, reportez-vous à la section Using the Explicit (Specific) Trust Scope.
Exemples de demandes et de réponses
Les exemples de demande et de réponse présentent le flux d'informations d'identification client à l'aide d'une portée qualifiée complète.
Exemple de demande
https://<domainURL>/oauth2/v1/authorize?
client_id=<client-id>&
response_type=code&
redirect_uri=<redirect-url>&
scope=http://abccorp.com/scope1 http://123corp.com/scope1 openid urn:opc:resource:multiresourcescope
curl -i
-H 'Authorization: Basic MzgzZTU4Z….NTM3YjFm' \
--request POST 'https://<domainURL>/oauth2/v1/token' \
-d 'grant_type=authorization_code' \
-d 'code=AgAgYjc1MzgzNWM2NGQxNDA5…YcxU_XdtfLWXUp1Vn4a5uIHiOn4='
curl -i
-H 'Authorization: Basic MzgzZTU4Z….NTM3YjFm' \
--request POST 'https://<domainURL>/oauth2/v1/token' \
-d 'grant_type=client_credentials' \
-d 'scope=http://abccorp.com/scope1 http://123corp.com/scope1 urn:opc:resource:multiresourcescope
Exemple de réponse
{
"tokenResponses":[
{
"access_token": "eyJ4NXQjUzI1NiI6InZBV3RzNEo1clE1Z.....1iZDc2NjFjMWJiZjA0OGNhOTkyMWNlN2Q4MThkNDY0YSIsImp0aSI6Ijg53ZFOT2FxyZYjocCnm1b1w",
"token_type": "Bearer",
"expires_in": 3600
},
{
"access_token": "eyJ4NXQjUzI1NiI6InZBV3RzNEo1clE1Z.....HplcmtUNjdsU19SjZlYjc5ZDgzMTVhYjQ0ODBiNDlkMjU3NzdkZWMzMDE2In0.k4QShMbO5aPGmYyKo",
"token_type": "Bearer",
"expires_in": 3000
}
],
"id_token": "eyJ4NXQjUzI1NiI6InZBV3RzNEo1clE1ZHplc.....mtUNjdsU19SYjhQTWoYDSVhTUmDl8zK3a9vk7cowIW2hr3smwtcsvfsbrewwtbnCrGerp7v4CUcVYlSw"
}