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

Si aucune portée 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 portées suivantes peuvent être indiquées dans les demandes de flux de connexion basées sur un navigateur à l'adresse /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).

Remarque

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.
Utilisez les directives suivantes lorsque vous utilisez 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 renvoyé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 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 de Explicit 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'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 la portée urn:opc:resource:consumer::all, le jeton d'accès obtenu n'inclut pas la portée urn: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.

Remarque

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 :

  1. Affectez la valeur de Account au paramètre trustScope pour l'application client sécurisée appropriée.

    Remarque

    L'attribut trustScope de Account est nommé Tout dans la console du domaine d'identité.

    Partie d'un exemple de demande avec une flèche rouge pointant vers le paramètre trustScope.

  2. 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'audience urn:opc:resource:scope:account et la portée urn: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.

Remarque

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

Outre l'utilisation de la portée 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

La portée demandée à partir de l'application client doit correspondre, directement ou hiérarchiquement, à au moins une des étendues autorisées du client pour permettre à ce dernier d'accéder à la ressource. Par exemple, une application client utilise la portée 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
}
Remarque

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.

Remarque

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 :

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

    Remarque

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

    Remarque

    Ces étapes supposent que l'application de ressource 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 ressource.

    Partie d'un exemple de demande avec des flèches rouges pointant vers le paramètre trustScope et le paramètre allowedTags.

  3. 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 public urn:opc:resource:scope:tag=<base64 encoded JSON> et la portée urn: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.

Remarque

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

Outre l'utilisation de la portée 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

La portée demandée à partir de l'application client doit correspondre, directement ou hiérarchiquement, à au moins une des étendues autorisées du client pour permettre à ce dernier d'accéder à la ressource. Par exemple, une application client utilise la portée 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
}
Remarque

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.

Remarque

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.

Remarque

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.

Pour utiliser cette fonctionnalité, procédez comme suit :
  • 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.
Remarque

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