Scopes

Mediante el parámetro de ámbito, el token de acceso puede otorgar diferentes niveles de acceso a varias API de dominio de identidad de IAM.

Los ámbitos proporcionan una forma de definir más específicamente un juego de recursos y operaciones que permite un token de acceso. Los ámbitos representan la intención. Cuando un cliente solicita un token de acceso, los ámbitos solicitados indican el tipo de funcionalidad que desea utilizar el cliente al presentar el token de acceso.

Además, los diferentes tipos de aplicaciones utilizan diferentes permisos de token de acceso. Las aplicaciones de confianza (como los servicios de backend) pueden solicitar tokens de acceso directamente en nombre de los usuarios. Las aplicaciones web normalmente necesitan primero validar la identidad del usuario y, opcionalmente, obtener el consentimiento del usuario.

Utilice el ámbito urn:opc:idm:__myscopes__ cuando necesite obtener un token de acceso que contenga todos los ámbitos de dominio de identidad permitidos. Se devuelven tokens de acceso que contienen todos los ámbitos de dominio de identidad aplicables en función de los privilegios representados por los roles de aplicación de dominio de identidad otorgados al cliente solicitante y al usuario especificado por la solicitud del cliente (si está presente). Este ámbito no se otorga directamente a ningún rol de administrador de dominio de identidad.

Utilice el ámbito urn:opc:idm:role.<r_name> (por ejemplo, urn:opc:idm:role.User%20Administrator) cuando necesite obtener un token de acceso que contenga los ámbitos aplicables de un rol específico, siempre que al cliente y al usuario se le otorgue el rol específico. Por ejemplo, para solicitar un token de acceso con un ámbito basado en roles de administrador de usuarios y administrador de aplicaciones:

Ejemplo de solicitud

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'

El token de acceso generado contendrá los ámbitos aplicables para el administrador de usuarios y el administrador de la aplicación, siempre que se otorguen estos roles al cliente y al usuario. Por ejemplo, un cliente tiene Role1, Role2 y Role3. Un usuario tiene Role1, Role2 y el rol 4. Los ámbitos incluidos en la solicitud para el token de acceso son Role1 y Role3. El token de acceso generado contendría solo ámbitos para Role1.

Las reclamaciones de ámbito pueden tener varios ámbitos separados por espacio. Si un nombre de ámbito contiene un espacio, el servidor no puede determinar el límite de ámbito correcto. Esto puede suceder cuando se utiliza un nombre de rol en el ámbito. En el ejemplo de solicitud, los roles "user administrator" y "application administrator" tienen espacios codificados en URL: scope=urn:opc:idm:role.User%2520Administrator urn:opc:idm:role.Application%2520Administrator.

Para evitar problemas de espacio en los nombres de rol, debe codificar los nombres de rol dos veces mediante la codificación de URL:

Ejemplo de código 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");

No se ha definido ningún ámbito para una aplicación

Si no hay ámbitos definidos para una aplicación (por ejemplo, si desea que el usuario simplemente se conecte y adquiera un token de acceso OAuth), se pueden especificar los siguientes ámbitos en las solicitudes de flujo de conexión basadas en explorador al punto final /oauth2/v1/authorize:
  • scope=openid: el token de acceso resultante se puede utilizar con /oauth2/c1/userinfo, que proporciona la información mínima del usuario.

  • scope=openid approles groups: el token de acceso resultante se puede utilizar con /oauth2/v1/userinfo para obtener los roles y grupos del usuario.

Uso de ámbitos de confianza

Los ámbitos de confianza definen cómo un cliente OAuth accede a los recursos. Los ámbitos de confianza permiten a una aplicación cliente de confianza o confidencial adquirir un token de acceso que proporciona acceso a cualquiera de los recursos de un dominio de identidad (Account), a otros recursos basados en etiquetas definidas (Tags) o solo a aquellos servicios en los que existe una asociación explícita entre el cliente y el servicio (Explicit).

Nota

La opción para definir el parámetro trustScope solo está disponible para aplicaciones cliente confidenciales y de confianza. La opción no está disponible para las aplicaciones de cliente públicas.
Utilice las siguientes directrices cuando utilice un ámbito de confianza:
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.
  • Utilice solo el ámbito urn:opc:resource:consumer::all en la solicitud. Se devolverá un error de ámbito no válido si intenta incluir tanto el ámbito urn:opc:resource:consumer::all como otro ámbito en la misma solicitud, como urn:opc:idm:__myscopes__.

  • La solicitud de un token de acceso mediante el ámbito urn:opc:resource:consumer::all no devuelve un token de acceso que proporcione acceso a las API de administrador de los dominios de identidad. Debe seguir utilizando el ámbito: urn:opc:idm:__myscopes__ para acceder a las API de administrador. Consulte Ámbitos.

  • El ámbito solicitado por la aplicación cliente siempre debe existir y coincidir, directa o jerárquicamente, con los ámbitos permitidos definidos del cliente para permitir el acceso del cliente al recurso.

  • El valor trustScope de Explicit se asigna por defecto a aplicaciones de cliente confidenciales y de confianza y permite a la aplicación cliente adquirir un token de acceso con permisos basados en una asociación explícita entre el cliente y los servicios de destino. Para utilizar la opción All o Tagged, debe actualizar la aplicación cliente con el valor trustScope de All o Tags.

  • Para las solicitudes de token de propagación de identidad que utilizan el ámbito urn:opc:resource:consumer::all, el token de acceso resultante no incluye el ámbito urn:opc:resource:consumer::all.

Los siguientes enlaces proporcionan más información sobre cada trustScope disponible:

Uso del ámbito de confianza de la cuenta

El ámbito de confianza Account permite a una aplicación cliente de confianza o confidencial obtener un token de acceso que proporciona acceso a cualquiera de los servicios que están en el mismo dominio de identidad sin necesidad de asociación explícita con los servicios de destino.

Nota

La opción para definir el parámetro trustScope solo está disponible para aplicaciones cliente confidenciales y de confianza. La opción no está disponible para las aplicaciones de cliente públicas.

Para utilizar el ámbito de confianza Account:

  1. Asigne el valor de Account al parámetro trustScope para la aplicación cliente de confianza adecuada.

    Nota

    El atributo trustScope de Account se denomina Todo en la consola del dominio de identidad.

    Parte de una solicitud de ejemplo con una flecha roja que apunta al parámetro trustScope.

  2. Solicite un token de acceso mediante el cliente confidencial o de confianza y solicite el ámbito urn:opc:resource:consumer::all. El token de acceso de la respuesta contiene el destinatario urn:opc:resource:scope:account y el ámbito urn:opc:resource:consumer::all, que proporciona acceso a cualquiera de los servicios que están en el mismo dominio sin necesidad de una asociación explícita con los servicios de destino.

Nota

El ámbito solicitado siempre debe existir y coincidir, directa o jerárquicamente, con los ámbitos permitidos definidos del cliente para permitir el acceso del cliente al recurso.

Uso de Ámbitos Detallados

Además de utilizar el ámbito urn:opc:resource:consumer::all, también puede especificar los siguientes ámbitos detallados:
  • urn:opc:resource:consumer:paas::read

  • urn:opc:resource:consumer:paas:stack::all

  • urn:opc:resource:consumer:paas:analytics::read

El ámbito solicitado de la aplicación cliente debe coincidir, directa o jerárquicamente, con al menos uno de los ámbitos permitidos del cliente para permitir el acceso del cliente al recurso. Por ejemplo, una aplicación cliente utiliza el ámbito urn:opc:resource:consumer:paas:analytics::read en su solicitud para acceder a un recurso. Si el ámbito coincide directamente con un ámbito permitido definido, en el token de acceso devuelto, el destinatario es urn:opc:resource:scope:account y el ámbito es urn:opc:resource:consumer:paas:analytics::read.

Si el ámbito permitido definido por el cliente es urn:opc:resource:consumer:paas::read, la aplicación cliente puede acceder al recurso jerárquicamente si el cliente solicita uno de los siguientes ámbitos: urn:opc:resource:consumer:paas::read o urn:opc:resource:consumer:paas:analytics::read. Sin embargo, si el ámbito solicitado es urn:opc:resource:consumer:paas:analytics::write,, el cliente no tiene permiso para acceder al recurso, porque no es uno de los ámbitos permitidos definidos por la aplicación cliente.

Ejemplos de solicitudes y respuestas

Los siguientes ejemplos muestran ejemplos de solicitud y respuesta para las credenciales de cliente y los flujos de otorgamiento de propietario de recurso.

Ejemplo de solicitud de flujo de credenciales de cliente

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

Ejemplo de respuesta

{
"access_token":"eyJ4NX....Zh3ieBlQ", 
"token_type":"Bearer", 
"expires_in":3600
}
Nota

El token de acceso contiene el público urn:opc:resource:scope:account y el ámbito urn:opc:resource:consumer::all.

Ejemplo de solicitud de flujo de propietario de recursos

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

Ejemplo de respuesta

{
"access_token":"eyJ4NX...71aImeBsU",
"token_type":"Bearer", 
"expires_in":3600
}

Ejemplos de solicitud y respuesta que utilizan un ámbito totalmente cualificado

Los siguientes ejemplos muestran ejemplos de solicitud y respuesta que utilizan un ámbito totalmente cualificado.

Ejemplo de solicitud

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'

Ejemplo de respuesta

{
"access_token":"eyJ4NXzF.....rT5SH7sUw", 
"token_type":"Bearer",
"expires_in":3600 
} 

Ejemplo de solicitud de flujo de propietario de recursos, incluida la solicitud de un token de refrescamiento

Para generar un token de refrescamiento además del token de acceso, utilice el ámbito urn:opc:resource:consumer::all offline_access en la solicitud.

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

Ejemplo de respuesta

{
"access_token":"eyJ4...pNYM0M", 
"token_type":"Bearer", 
"expires_in":3600,
"refresh_token":"AQIDBAUi....djF9NCA=" 
}

Uso del ámbito de confianza de etiquetas

El ámbito de confianza Tags permite a una aplicación cliente de confianza o confidencial obtener un token de acceso que proporciona acceso a otros recursos según las etiquetas definidas.

Nota

La opción para definir el parámetro trustScope solo está disponible para aplicaciones cliente confidenciales y de confianza. La opción no está disponible para las aplicaciones de cliente públicas.

Para utilizar el ámbito de confianza Tags:

  1. Asigne el valor de Tags al parámetro trustScope para permitir que la aplicación cliente acceda a las etiquetas de otras aplicaciones.

    Nota

    El atributo trustScope de Tags se denomina Etiquetado en la consola del dominio de identidad.
  2. Defina el par key:value para el parámetro AllowedTags.

    Nota

    En estos pasos se asume que la aplicación de recursos adecuada ha definido pares key:value para el atributo Tags y que al menos un par key:value de la lista del atributo allowedTags de la aplicación cliente coincide con un par key:value del atributo Tags de la aplicación de recursos.

    Parte de una solicitud de ejemplo con flechas rojas que apuntan al parámetro trustScope y al parámetro allowedTags.

  3. Solicite un token de acceso mediante el cliente confidencial o de confianza y solicite el ámbito urn:opc:resource:consumer::all. El token de acceso de la respuesta contiene el destinatario urn:opc:resource:scope:tag=<base64 encoded JSON> y el ámbito urn:opc:resource:consumer::all, que proporciona acceso a las aplicaciones de recursos que tienen etiquetas que coinciden con las etiquetas permitidas especificadas en la aplicación cliente.

Nota

El ámbito solicitado siempre debe existir y coincidir, directa o jerárquicamente, con los ámbitos permitidos definidos del cliente para permitir el acceso del cliente al recurso.

Uso de Ámbitos Detallados

Además de utilizar el ámbito urn:opc:resource:consumer::all, también puede especificar los siguientes ámbitos detallados:
  • urn:opc:resource:consumer:paas::read

  • urn:opc:resource:consumer:paas:stack::all

  • urn:opc:resource:consumer:paas:analytics::read

El ámbito solicitado de la aplicación cliente debe coincidir, directa o jerárquicamente, con al menos uno de los ámbitos permitidos del cliente para permitir el acceso del cliente al recurso. Por ejemplo, una aplicación cliente utiliza el ámbito urn:opc:resource:consumer:paas:analytics::read en su solicitud para acceder a un recurso. Si el ámbito coincide directamente con un ámbito permitido definido, en el token de acceso devuelto el destinatario es urn:opc:resource:scope:tag=<base64 encoded JSON> y el ámbito es urn:opc:resource:consumer:paas:analytics::read.

Si el ámbito permitido definido por el cliente es urn:opc:resource:consumer:paas::read, la aplicación cliente puede acceder al recurso jerárquicamente si el cliente solicita uno de los siguientes ámbitos: urn:opc:resource:consumer:paas::read o urn:opc:resource:consumer:paas:analytics::read. Sin embargo, si el ámbito solicitado es urn:opc:resource:consumer:paas:analytics::write,, el cliente no tiene permiso para acceder al recurso, porque no es uno de los ámbitos permitidos definidos por la aplicación cliente.

Ejemplos de solicitudes y respuestas

Los siguientes ejemplos muestran ejemplos de solicitud y respuesta para el flujo de credenciales de cliente mediante el ámbito urn:opc:resource:consumer::all.

Ejemplo de solicitud

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'

Ejemplo de respuesta

{
"access_token""eyJ4NX....ZbDtAw", 
"token_type":"Bearer", "expires_in":3600
}
Nota

El token de acceso contiene el público urn:opc:resource:scope:tag=<base64 encoded JSON> y el ámbito urn:opc:resource:consumer::all. A continuación se muestra un ejemplo de audiencia decodificada: aud:["urn:opc:resource:scope:tag=eyAidGFncyI6WyB7ICJrZXkiOiJjb2xvciIsInZhbHVlIjoiZ3JlZW4ifSAsICB7ICJrZXkiOiJjb2xvciIsInZhbHVlIjoiYmx1ZSJ9IF19"]

Los siguientes ejemplos muestran ejemplos de solicitud y respuesta para el flujo de credenciales de cliente mediante un ámbito totalmente cualificado.

Ejemplo de solicitud

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'

Ejemplo de respuesta

{
"access_token""eyJ4NXzF.....rT5SH7sUw", 
"token_type":"Bearer",
"expires_in":3600 
} 

Uso del ámbito de confianza explícito

El ámbito de confianza Explicit define el ámbito de confianza solo para aquellos servicios en los que existe una asociación explícita entre el cliente y el servicio de destino.

Nota

La opción para definir el parámetro trustScope solo está disponible para aplicaciones cliente confidenciales y de confianza. La opción no está disponible para las aplicaciones de cliente públicas.

No tiene que hacer nada para utilizar el ámbito de confianza Explicit porque este es el valor por defecto asignado a la aplicación cliente de confianza y confidencial. Para utilizar la opción Account o Tags, debe actualizar la aplicación cliente con el valor trustScope de Account o Tags.

Nota

El atributo trustScope de Explicit se denomina Específico en el dominio de identidad.

Consulte Uso del ámbito de confianza de cuenta y Uso del ámbito de confianza de etiquetas.

Ejemplos de solicitudes y respuestas

Los ejemplos de solicitud y respuesta muestran el flujo de credenciales de cliente mediante un ámbito totalmente cualificado.

Ejemplo de solicitud

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'

Ejemplo de respuesta

{
"access_token""eyJ4NXzF.....rT5SH7sUw", 
"token_type":"Bearer",
"expires_in":3600 
}

Uso de ámbitos de confianza explícitos desde varios recursos

El ámbito de confianza Explicit define el ámbito de confianza solo para aquellos servicios en los que existe una asociación explícita entre el cliente y el servicio de destino. Puede especificar varios ámbitos que pertenezcan a diferentes recursos en una única solicitud de autorización o solicitud de token y obtener varios tokens de acceso a cambio con cada uno de ellos que contenga los ámbitos para cada recurso.

Para utilizar esta función:
  • Debe especificar el ámbito recién definido, urn:opc:resource:multiresourcescope, en la solicitud de autorización o en la solicitud de token. Las solicitudes de token fallarán si se especifican varios ámbitos que pertenecen a recursos diferentes sin este ámbito.
  • El cliente OAuth debe poder analizar la respuesta del token que incluye varios tokens de acceso y utilizar cada token para acceder a cada servicio de recursos.
Nota

Puede utilizar esta función con todos los tipos de permiso excepto para el flujo implícito. Consulte Tipo de permiso implícito.

Consulte Uso del ámbito de confianza explícito (específico) para obtener más información sobre los ámbitos de confianza explícitos.

Ejemplos de solicitudes y respuestas

Los ejemplos de solicitud y respuesta muestran el flujo de credenciales de cliente mediante un ámbito totalmente cualificado.

Ejemplo de solicitud

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

Ejemplo de respuesta

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