Escopos

Usando o parâmetro de escopo, o token de acesso pode conceder diferentes níveis de acesso a várias APIs de domínio de identidades do IAM.

Os escopos fornecem uma maneira de definir mais especificamente um conjunto de recursos e operações que um token de acesso permite. Os escopos representam a intenção. Quando um cliente solicita uma ficha de acesso, os escopos solicitados indicam o tipo de funcionalidade a ser usada pelo cliente ao apresentar a ficha.

Além disso, diferentes tipos de aplicativos usam diferentes concessões de token de acesso. Aplicativos confiáveis (como serviços de back-end) podem solicitar tokens de acesso diretamente em nome dos usuários. Os aplicativos da Web geralmente precisam primeiro validar a identidade do usuário e, opcionalmente, obter o consentimento do usuário.

Use o escopo urn:opc:idm:__myscopes__ quando precisar obter um token que contenha todos os escopos de domínio de identidades permitidos. São retornados tokens de acesso que contêm todos os escopos de domínio de identidades aplicáveis com base nos privilégios representados pelas atribuições de aplicativo de domínio de identidades concedidas ao cliente solicitante e ao usuário que está sendo especificado pela solicitação do cliente (se presente). Este escopo não é concedido diretamente a nenhuma atribuição de administrador de domínio de identidades.

Use o escopo urn:opc:idm:role.<r_name> (por exemplo, urn:opc:idm:role.User%20Administrator) quando precisar obter um token de acesso que contenha os escopos aplicáveis de uma atribuição específica, desde que o cliente e o usuário recebam a atribuição específica. Por exemplo, para solicitar um token de acesso com um escopo baseado em função do administrador do usuário e do administrador do aplicativo:

Exemplo de Solicitação

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'

O token de acesso gerado conterá os escopos aplicáveis para o administrador de usuários e o administrador de aplicativos, desde que o cliente e o usuário recebam essas atribuições. Por exemplo, um cliente tem Role1, Role2 e Role3. Um Usuário tem Role1, Role2 e Atribuição 4. Os escopos incluídos na solicitação do token de acesso são Role1 e Role3. O token de acesso gerado conteria apenas escopos para Role1.

As reivindicações de escopo podem ter vários escopos separados por espaço. Se um nome de escopo contiver um espaço, o servidor não poderá determinar o limite de escopo correto. Isso pode acontecer quando um nome de função é usado no escopo. No exemplo de solicitação, as atribuições "administrador de usuários" e "administrador de aplicativos" têm espaços que foram codificados por URL: scope=urn:opc:idm:role.User%2520Administrator urn:opc:idm:role.Application%2520Administrator.

Para evitar problemas de espaço nos nomes de função, você deve codificar os nomes de função duas vezes usando a codificação de URL:

Exemplo 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");

Nenhum Escopo Definido para um Aplicativo

Se não houver escopos definidos para um aplicativo (por exemplo, querer que o usuário simplesmente acesse e adquira um token de acesso OAuth), os seguintes escopos poderão ser especificados nas solicitações de fluxo de log-in baseadas em browser para o ponto final /oauth2/v1/authorize:
  • scope=openid: O token de acesso resultante pode ser usado com o /oauth2/c1/userinfo, que fornece as informações mínimas do usuário.

  • scope=openid approles groups: O token de acesso resultante pode ser usado com o /oauth2/v1/userinfo para obter as atribuições e grupos do usuário.

Usando Escopos Confiáveis

Os escopos de confiança definem como um cliente OAuth acessa recursos. Os escopos de confiança permitem que um aplicativo cliente confiável ou confidencial adquira um token de acesso que dá acesso a qualquer um dos recursos em um domínio de identidades (Account), a outros recursos baseados em tags definidas (Tags) ou apenas aos serviços em que existe uma associação explícita entre o cliente e o serviço (Explicit).

Observação

A opção para definir o parâmetro trustScope está disponível apenas para aplicativos clientes confiáveis e confidenciais. A opção não está disponível para aplicativos clientes públicos.
Use as seguintes diretrizes ao usar um escopo confiável:
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.
  • Use apenas o escopo urn:opc:resource:consumer::all na solicitação. Um erro de escopo inválido será retornado se você tentar incluir o escopo urn:opc:resource:consumer::all e outro escopo na mesma solicitação, como urn:opc:idm:__myscopes__.

  • A solicitação de um token de acesso usando o escopo urn:opc:resource:consumer::all não retorna um token de acesso que fornece acesso às APIs de administrador de domínios de identidade. Você deve continuar usando o escopo urn:opc:idm:__myscopes__ para acessar as APIs de administração. Consulte Escopos.

  • O escopo requisitado pelo aplicativo Cliente deve sempre existir e corresponder, direta ou hierarquicamente, aos escopos permitidos definidos pelo cliente para permitir que o cliente acesse o recurso.

  • O valor trustScope de Explicit é designado por padrão a aplicativos cliente confiáveis e confidenciais e permite que seu aplicativo cliente adquira um token de acesso com permissões baseadas em uma associação explícita entre o cliente e os serviços de destino. Para usar a opção All ou Tagged, você deve atualizar o aplicativo cliente com o valor trustScope de All ou Tags.

  • Para solicitações de token de propagação de identidade usando o escopo urn:opc:resource:consumer::all, o token de acesso resultante não inclui o escopo urn:opc:resource:consumer::all.

Os links a seguir fornecem mais informações sobre cada trustScope disponível:

Usando o Escopo de Confiança da Conta

O escopo de confiança Account permite que um aplicativo cliente confiável ou confidencial obtenha um token de acesso que dá acesso a qualquer um dos serviços que estão no mesmo domínio de identidades sem exigir associação explícita com os serviços de destino.

Observação

A opção para definir o parâmetro trustScope está disponível apenas para aplicativos clientes confiáveis e confidenciais. A opção não está disponível para aplicativos clientes públicos.

Para usar o escopo confiável Account:

  1. Designe o valor de Account ao parâmetro trustScope para o aplicativo cliente confiável apropriado.

    Observação

    O atributo trustScope de Account é nomeado Todos na Console do domínio de identidades.

    Parte de uma solicitação de exemplo com uma seta vermelha apontando para o parâmetro trustScope.

  2. Solicite um token de acesso usando o cliente confiável ou confidencial e solicite o escopo urn:opc:resource:consumer::all. O token de acesso na resposta contém o público urn:opc:resource:scope:account e o escopo urn:opc:resource:consumer::all, que dá acesso a qualquer um dos serviços que estejam no mesmo domínio sem exigir associação explícita com o serviço de destino.

Observação

O escopo solicitado sempre deve existir e corresponder, direta ou hierarquicamente, aos escopos permitidos definidos pelo cliente para permitir o acesso do cliente ao recurso.

Usando Escopos Detalhados

Além de usar o escopo urn:opc:resource:consumer::all, você também pode especificar os seguintes escopos detalhados:
  • urn:opc:resource:consumer:paas::read

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

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

O escopo solicitado do aplicativo cliente deve corresponder, direta ou hierarquicamente, a pelo menos um dos escopos permitidos do cliente para permitir o acesso do cliente ao recurso. Por exemplo, um aplicativo cliente usa o escopo urn:opc:resource:consumer:paas:analytics::read em sua solicitação de acesso a um recurso. Se o escopo corresponder diretamente com um escopo permitido, no token de acesso retornado, o público-alvo será o urn:opc:resource:scope:account e o escopo será o urn:opc:resource:consumer:paas:analytics::read.

Se o escopo permitido definido pelo cliente for urn:opc:resource:consumer:paas::read, o aplicativo cliente poderá acessar o recurso hierarquicamente se o cliente solicita um dos seguintes escopos: urn:opc:resource:consumer:paas::read ou urn:opc:resource:consumer:paas:analytics::read. No entanto, se o escopo solicitado for urn:opc:resource:consumer:paas:analytics::write,, o cliente não terá permissão de acesso ao recurso, porque esse não será um dos escopos permitidos definidos pelo aplicativo cliente.

Exemplos de Solicitação e Resposta

Os exemplos a seguir mostram exemplos de solicitação e resposta para as credenciais do cliente e fluxos de concessão do proprietário do recurso.

Exemplo de Solicitação de Fluxo de Credenciais do 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

Exemplo de Resposta

{
"access_token":"eyJ4NX....Zh3ieBlQ", 
"token_type":"Bearer", 
"expires_in":3600
}
Observação

O token de acesso contém o público-alvo urn:opc:resource:scope:account e o escopo urn:opc:resource:consumer::all.

Exemplo de Solicitação de Fluxo do Proprietário do Recurso

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

Exemplo de Resposta

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

Exemplos de Solicitação e Resposta Usando um Escopo Totalmente Qualificado

Os exemplos a seguir mostram exemplos de solicitação e resposta usando um escopo totalmente qualificado.

Exemplo de Solicitação

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'

Exemplo de Resposta

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

Exemplo de Solicitação de Fluxo do Proprietário do Recurso Incluindo a Solicitação de um Token de Atualização

Para gerar um token de atualização além do token de acesso, use o escopo urn:opc:resource:consumer::all offline_access na solicitação.

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

Exemplo de Resposta

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

Usando o Escopo de Confiança de Tags

O escopo de confiança Tags permite que um aplicativo cliente confiável ou confidencial obtenha um token de acesso que dá acesso a outros recursos com base nas tags definidas.

Observação

A opção para definir o parâmetro trustScope está disponível apenas para aplicativos clientes confiáveis e confidenciais. A opção não está disponível para aplicativos clientes públicos.

Para usar o escopo confiável Tags:

  1. Designe o valor de Tags ao parâmetro trustScope para permitir que o aplicativo cliente acesse tags de outros aplicativos.

    Observação

    O atributo trustScope de Tags é nomeado Marcado com Tag na Console do domínio de identidades.
  2. Defina o par key:value para o parâmetro AllowedTags.

    Observação

    Essas etapas pressupõem que o Aplicativo de Recurso apropriado tenha definido pares key:value para o atributo Tags e que pelo menos um par key:value da lista do atributo allowedTags do Aplicativo Cliente corresponda a um par key:value do atributo Tags do Aplicativo de Recurso.

    Uma parte de uma solicitação de exemplo com setas vermelhas apontando para o parâmetro trustScope e o parâmetro allowedTags.

  3. Solicite um token de acesso usando o cliente confiável ou confidencial e solicite o escopo urn:opc:resource:consumer::all. O token de acesso na resposta contém o público-alvo urn:opc:resource:scope:tag=<base64 encoded JSON> e o escopo urn:opc:resource:consumer::all, que dá acesso aos Aplicativos de Recursos que têm tags que correspondem às tags permitidas especificadas no Aplicativo Cliente.

Observação

O escopo solicitado sempre deve existir e corresponder, direta ou hierarquicamente, aos escopos permitidos definidos pelo cliente para permitir o acesso do cliente ao recurso.

Usando Escopos Detalhados

Além de usar o escopo urn:opc:resource:consumer::all, você também pode especificar os seguintes escopos detalhados:
  • urn:opc:resource:consumer:paas::read

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

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

O escopo solicitado do aplicativo cliente deve corresponder, direta ou hierarquicamente, a pelo menos um dos escopos permitidos do cliente para permitir o acesso do cliente ao recurso. Por exemplo, um aplicativo cliente usa o escopo urn:opc:resource:consumer:paas:analytics::read em sua solicitação de acesso a um recurso. Se o escopo corresponder diretamente ao escopo permitido definido, no token de acesso retornado, o público-alvo é urn:opc:resource:scope:tag=<base64 encoded JSON> e o escopo é urn:opc:resource:consumer:paas:analytics::read.

Se o escopo permitido definido pelo cliente for urn:opc:resource:consumer:paas::read, o aplicativo cliente poderá acessar o recurso hierarquicamente se o cliente solicita um dos seguintes escopos: urn:opc:resource:consumer:paas::read ou urn:opc:resource:consumer:paas:analytics::read. No entanto, se o escopo solicitado for urn:opc:resource:consumer:paas:analytics::write,, o cliente não terá permissão de acesso ao recurso, porque esse não será um dos escopos permitidos definidos pelo aplicativo cliente.

Exemplos de Solicitação e Resposta

Os exemplos a seguir mostram exemplos de solicitação e resposta para o fluxo de credenciais do cliente usando o escopo urn:opc:resource:consumer::all.

Exemplo de Solicitação

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'

Exemplo de Resposta

{
"access_token""eyJ4NX....ZbDtAw", 
"token_type":"Bearer", "expires_in":3600
}
Observação

O token de acesso contém o público-alvo urn:opc:resource:scope:tag=<base64 encoded JSON> e o escopo urn:opc:resource:consumer::all. Veja a seguir um exemplo de público-alvo decodificado: aud:["urn:opc:resource:scope:tag=eyAidGFncyI6WyB7ICJrZXkiOiJjb2xvciIsInZhbHVlIjoiZ3JlZW4ifSAsICB7ICJrZXkiOiJjb2xvciIsInZhbHVlIjoiYmx1ZSJ9IF19"]

Os exemplos a seguir mostram exemplos de solicitação e resposta para o fluxo de credenciais do cliente usando um escopo totalmente qualificado.

Exemplo de Solicitação

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'

Exemplo de Resposta

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

Usando o Escopo de Confiança Explícita

O escopo de confiança Explicit define o escopo de confiança somente para os serviços em que existe uma associação explícita entre o cliente e o serviço de destino.

Observação

A opção para definir o parâmetro trustScope está disponível apenas para aplicativos clientes confiáveis e confidenciais. A opção não está disponível para aplicativos clientes públicos.

Você não precisa fazer nada para usar o escopo de confiança Explicit porque esse é o padrão atribuído ao aplicativo cliente confiável e confidencial. Para usar a opção Account ou Tags, você deve atualizar o aplicativo cliente com o valor trustScope de Account ou Tags.

Observação

O atributo trustScope de Explicit é nomeado Específico no domínio de identidades.

Consulte Usando o Escopo de Confiabilidade da Conta e Usando o Escopo de Confiabilidade de Tags.

Exemplos de Solicitação e Resposta

Os exemplos de solicitação e resposta mostram o fluxo de credenciais do cliente usando um escopo totalmente qualificado.

Exemplo de Solicitação

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'

Exemplo de Resposta

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

Usando Escopos de Confiança Explícitos de Vários Recursos

O escopo de confiança Explicit define o escopo de confiança somente para os serviços em que existe uma associação explícita entre o cliente e o serviço de destino. Você pode especificar vários escopos pertencentes a diferentes recursos em uma única solicitação de Autorização ou solicitação de token e obter vários tokens de acesso em troca de cada um deles contendo os escopos de cada recurso.

Para usar esse recurso:
  • Especifique o escopo recém-definido, urn:opc:resource:multiresourcescope na solicitação de Autorização ou na solicitação de token. As solicitações de token falharão se vários escopos pertencentes a recursos diferentes forem especificados sem esse escopo.
  • O Cliente OAuth deve poder fazer parsing da resposta do token que inclui vários tokens de acesso e usar cada token para acessar cada serviço de recurso.
Observação

Você pode usar esse recurso com todos os tipos de concessão, exceto o fluxo Implícito. Consulte Tipo de Concessão Implícita.

Consulte Usando o Escopo de Confiança Explícito (Específico) para obter mais informações sobre os escopos de confiança explícitos.

Exemplos de Solicitação e Resposta

Os exemplos de solicitação e resposta mostram o fluxo de credenciais do cliente usando um escopo totalmente qualificado.

Exemplo de Solicitação

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

Exemplo de Resposta

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