Portées

À 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 qu'un jeton d'accès autorise. 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é qu'un client veut utiliser lors de la présentation du jeton d'accès.

En outre, différents types d'application utilisent des autorisations de jeton d'accès différentes. Les applications approuvées (telles que les services dorsaux) 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 l'étendue urn:opc:idm:__myscopes__ lorsque vous avez besoin d'obtenir un jeton d'accès contenant toutes les étendues de domaine d'identité autorisées. Les jetons d'accès retournés contiennent toutes les étendues de domaine d'identité applicables 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 étendue n'est octroyée directement à aucun rôle d'administrateur de domaine d'identité.

Utilisez l'étendue urn:opc:idm:role.<r_name> (par exemple, urn:opc:idm:role.User%20Administrator) lorsque vous avez besoin d'obtenir un jeton d'accès contenant les étendues applicables d'un rôle spécifique, à condition que le rôle spécifique soit accordé au client et à l'utilisateur. Par exemple, pour demander un jeton d'accès avec une portée basée sur les rôles d'administrateur d'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 étendues applicables pour l'administrateur d'utilisateur et l'administrateur d'application tant que ces rôles sont accordés au client et à l'utilisateur. Par exemple, un client a Role1, Role2 et Role3. Un utilisateur a Role1, Role2 et le rôle 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é ne contient que des étendues pour Role1.

Les revendications de portée peuvent avoir plusieurs étendues séparées par des espaces. Si un nom d'étendue contient un espace, le serveur ne peut pas déterminer la limite d'étendue correcte. Cela peut se produire lorsqu'un nom de rôle est utilisé dans l'étendue. Dans l'exemple de demande, les rôles "administrateur d'utilisateur" et "administrateur d'application" ont des espaces qui ont été encodés par 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 étendue définie pour une application

Si aucune étendue n'est définie pour une application (par exemple, si l'utilisateur souhaite simplement se connecter et acquérir un jeton d'accès OAuth), les étendues suivantes peuvent être spécifiées dans les demandes de flux de connexion basées sur le navigateur au point d'extrémité /oauth2/v1/authorize :

scope=openid : Le jeton d'accès obtenu peut être utilisé avec /oauth2/c1/userinfo, qui fournit le minimum d'informations sur l'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 d'approbation définissent comment un client OAuth accède aux ressources. Les portées d'approbation permettent à une application client approuvé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 marqueurs définis (Tags) ou uniquement aux services pour lesquels une association explicite entre le client et le service (Explicit) existe.

Note

L'option permettant de définir le paramètre trustScope est disponible uniquement pour les applications client fiables et confidentielles. L'option n'est pas disponible pour les applications client publiques.

Utilisez les directives suivantes lors de l'utilisation d'une portée d'approbation :

Note

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 retournée si vous tentez d'inclure à la fois la portée urn:opc:resource:consumer::all et une autre portée dans la même demande, par exemple urn:opc:idm:__myscopes__.
La demande d'un jeton d'accès à l'aide de l'étendue urn:opc:resource:consumer::all ne retourne pas de jeton d'accès qui fournit l'accès aux API d'administration des domaines d'identité. Vous devez continuer d'utiliser la portée : urn:opc:idm:__myscopes__ pour accéder aux API d'administration. Voir Portées.
La portée demandée par l'application client doit toujours exister et correspondre, directement ou hiérarchiquement, aux portées autorisées du client pour permettre l'accès du client à la ressource.
La valeur trustScope de Explicit est affectée par défaut aux applications client fiables et confidentielles et permet à votre application client d'acquérir un jeton d'accès avec des autorisations basées sur une association explicite entre le client et les services cibles. Pour utiliser l'option All ou Tagged, vous devez mettre à jour l'application client avec la valeur trustScope All ou Tags.
Pour les demandes de jeton de propagation d'identité utilisant l'étendue urn:opc:resource:consumer::all, le jeton d'accès résultant n'inclut pas l'étendue urn:opc:resource:consumer::all.

Les liens suivants fournissent plus d'informations sur chaque trustScope disponible :

Utilisation de la portée de la fiducie du compte

L'étendue d'approbation Account permet à une application client approuvée ou confidentielle d'obtenir un jeton d'accès qui donne accès à l'un des services du même domaine d'identité sans nécessiter d'association explicite avec les services cibles.

Pour utiliser l'étendue d'approbation Account :

Affectez la valeur Account au paramètre trustScope pour l'application client approuvée appropriée.

Note

L'attribut trustScope de Account est nommé Tout dans la console du domaine d'identité.
Demandez un jeton d'accès à l'aide du client approuvé ou confidentiel et demandez la portée urn:opc:resource:consumer::all. Le jeton d'accès dans la réponse contient le public urn:opc:resource:scope:account et la portée urn:opc:resource:consumer::all, ce qui donne accès à tous les services du même domaine sans nécessiter d'association explicite avec les services cibles.

Note

La portée demandée doit toujours exister et correspondre, directement ou hiérarchiquement, aux portées autorisées du client pour permettre l'accès du client à la ressource.

Utiliser des portées de niveau fin

Outre l'utilisation de la portée urn:opc:resource:consumer::all, vous pouvez spécifier 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

La portée demandée dans l'application client doit correspondre, directement ou hiérarchiquement, à au moins une des portées autorisées du client pour permettre l'accès du client à la ressource. Par exemple, une application client utilise la portée urn:opc:resource:consumer:paas:analytics::read dans sa demande d'accès à une ressource. Si la portée correspond directement à une portée autorisée définie, le public est urn:opc:resource:scope:account dans le jeton d'accès retourné 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 hiérarchiquement 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 demande et de réponse

Les exemples suivants présentent des exemples de demande et de réponse pour les données d'identification du client et les flux d'octroi du responsable de la ressource.

Exemple de demande de flux de données d'identification de 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
}

Note

Le jeton d'accès contient le public urn:opc:resource:scope:account et la portée urn:opc:resource:consumer::all.

Exemple de demande de flux de responsable 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 entièrement qualifiée.

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 responsable de ressource incluant la demande d'un jeton d'actualisation

Pour 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 de confiance des marqueurs

L'étendue d'approbation Tags permet à une application client approuvée ou confidentielle d'obtenir un jeton d'accès qui donne accès à d'autres ressources en fonction des marqueurs définis.

Pour utiliser l'étendue d'approbation Tags :

Affectez la valeur Tags au paramètre trustScope pour permettre à l'application client d'accéder à des marqueurs d'autres applications.

Note

L'attribut trustScope de Tags est nommé Marqué dans la console du domaine d'identité.
Définissez la paire key:value pour le paramètre AllowedTags.

Note

Ces étapes supposent que l'application de ressources appropriée a défini des paires key:value pour l'attribut Tags et qu'au moins une paire key:value de la liste de l'attribut allowedTags de l'application client correspond à une paire key:value de l'attribut Tags de l'application de ressources.
Demandez un jeton d'accès à l'aide du client approuvé ou confidentiel et demandez la portée urn:opc:resource:consumer::all. Le jeton d'accès dans la réponse contient le public urn:opc:resource:scope:tag=<base64 encoded JSON> et la portée urn:opc:resource:consumer::all, ce qui donne accès aux applications de ressources dont les marqueurs correspondent aux marqueurs autorisés spécifiés dans l'application client.

Note

La portée demandée doit toujours exister et correspondre, directement ou hiérarchiquement, aux portées autorisées du client pour permettre l'accès du client à la ressource.

Utiliser des portées de niveau fin

Outre l'utilisation de la portée urn:opc:resource:consumer::all, vous pouvez spécifier 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

La portée demandée dans l'application client doit correspondre, directement ou hiérarchiquement, à au moins une des portées autorisées du client pour permettre l'accès du client à la ressource. Par exemple, une application client utilise la portée urn:opc:resource:consumer:paas:analytics::read dans sa demande d'accès à une ressource. Si la portée correspond directement à une portée autorisée définie, le public est urn:opc:resource:scope:tag=<base64 encoded JSON> dans le jeton d'accès retourné et la portée est urn:opc:resource:consumer:paas:analytics::read.

Exemples de demande et de réponse

Les exemples suivants présentent des exemples de demande et de réponse pour le flux de données d'identification de 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
}

Note

Le jeton d'accès contient le public 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 de données d'identification du client à l'aide d'une portée entièrement qualifiée.

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 de la portée de confiance explicite

La portée de confiance Explicit définit la portée de confiance uniquement pour les services pour lesquels il existe une association explicite entre le client et le service cible.

Vous n'avez rien à faire pour utiliser l'étendue d'approbation Explicit, car il s'agit de la valeur par défaut affectée à l'application client approuvée et confidentielle. Pour utiliser l'option Account ou Tags, vous devez mettre à jour l'application client avec la valeur trustScope Account ou Tags.

Note

L'attribut trustScope de Explicit est nommé Spécifique dans le domaine d'identité.

Voir Utilisation de l'étendue de confiance du compte et Utilisation de l'étendue de confiance des marqueurs.

Exemples de demande et de réponse

Les exemples de demande et de réponse montrent le flux des données d'identification du client à l'aide d'une portée entièrement qualifiée.

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 de confiance Explicit définit la portée de confiance uniquement pour les services pour lesquels il existe une association explicite entre le client et le service cible. Vous pouvez spécifier plusieurs étendues appartenant à différentes ressources dans une seule demande d'autorisation ou demande de jeton et obtenir plusieurs jetons d'accès en retour, chacun contenant les étendues pour chaque ressource.

Pour utiliser cette fonction :

Vous devez spécifier la portée nouvellement définie, urn:opc:resource:multiresourcescope dans la demande d'autorisation ou la demande de jeton. Les demandes de jeton échoueront si plusieurs étendues appartenant à des ressources différentes sont spécifiées sans cette étendue.
Le client OAuth doit pouvoir analyser la réponse du jeton qui inclut plusieurs jetons d'accès et utiliser chaque jeton pour accéder à chaque service de ressources.

Note

Vous pouvez utiliser cette fonction avec tous les types d'autorisation, à l'exception du flux implicite. Voir Type de droit implicite.

Voir Utilisation de la portée de confiance explicite (spécifique) pour plus d'informations sur les portées de confiance explicites.

Exemples de demande et de réponse

Les exemples de demande et de réponse montrent le flux des données d'identification du client à l'aide d'une portée entièrement qualifiée.

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" 
}

Documentation sur Oracle Cloud Infrastructure

Portées

Utilisation des portées de confiance

Utilisation de la portée de la fiducie du compte

Utilisation de la portée de confiance des marqueurs

Utilisation de la portée de confiance explicite

Utilisation des portées de confiance explicites à partir de plusieurs ressources