Scopes

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 serviço 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 um token de acesso, os escopos solicitam a indicação do tipo de funcionalidade que um cliente deseja usar ao apresentar o token de acesso.

Além disso, diferentes tipos de aplicativos usam diferentes concessões de token de acesso. Aplicativos confiáveis (como serviços de backend) podem solicitar tokens de acesso diretamente em nome dos usuários. Os aplicativos 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 de acesso 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). Esse 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 atribuição de administrador de usuários e administrador de aplicativos:

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 conteria os escopos aplicáveis para o administrador do usuário e o administrador do aplicativo, 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 atribuição é usado no escopo. No exemplo de solicitação, as atribuições "administrador do usuário" e "administrador do aplicativo" 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 atribuição, você deve codificar os nomes de atribuiçã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, desejar que o usuário simplesmente acesse e adquira um token de acesso OAuth), os seguintes escopos poderão ser especificados em 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 /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 /oauth2/v1/userinfo para obter as atribuições e os grupos do usuário.

Usando Escopos Confiáveis

Os escopos confiáveis 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 dentro de um domínio de identidades (Account), a outros recursos com base em tags definidas (Tags) ou apenas aos serviços nos quais 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 só está disponível 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 administrativas dos domínios de identidades. Você deve continuar a usar o escopo: urn:opc:idm:__myscopes__ para acessar as APIs administrativas. Consulte Escopos.
O escopo solicitado pelo aplicativo Cliente sempre deve existir e corresponder, direta ou hierarquicamente, aos escopos permitidos definidos pelo cliente para permitir o acesso do cliente ao recurso.
O valor trustScope de Explicit é designado por padrão a aplicativos clientes 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, atualize 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 Confiável da Conta

O escopo confiável 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 estejam no mesmo domínio de identidades sem exigir associação explícita com os serviços de destino.

Para usar o escopo confiável Account:

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

Observação

O atributo trustScope de Account é chamado de Tudo na Console do domínio de identidades.
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:account e o escopo urn:opc:resource:consumer::all, que dá acesso a qualquer um dos serviços que estão no mesmo domínio sem exigir associação explícita com os serviços 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 para acesso a um recurso. Se o escopo corresponder diretamente a um escopo permitido definido, no token de acesso retornado, o público-alvo será urn:opc:resource:scope:account e o escopo será urn:opc:resource:consumer:paas:analytics::read.

Se o escopo permitido definido pelo cliente for urn:opc:resource:consumer:paas::read, o aplicativo cliente terá permissão para acessar o recurso hierarquicamente se o cliente solicitar 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 permitirá acesso ao recurso porque ele 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 Confiável de Tags

O escopo confiável 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.

Para usar o escopo confiável Tags:

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 é chamado de Marcado com Tag na Console do domínio de identidades.
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.
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 para acesso a um recurso. Se o escopo corresponder diretamente a um escopo permitido definido, no token de acesso retornado, o público-alvo será urn:opc:resource:scope:tag=<base64 encoded JSON> e o escopo será urn:opc:resource:consumer:paas:analytics::read.

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 Confiável Explícito

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

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

Observação

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

Consulte Usando o Escopo Confiável da Conta e Usando o Escopo Confiável 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 os Escopos Confiáveis Explícitos de Vários Recursos

O escopo de confiança Explicit define o escopo de confiança apenas 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 com 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 diferentes recursos forem especificados sem esse escopo.
O Cliente OAuth deve ser capaz de 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 para o fluxo Implícito. Consulte Tipo de Concessão Implícita.

Consulte Usando o Escopo Confiável 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" 
}

Documentação do Oracle Cloud Infrastructure

Scopes

Usando Escopos Confiáveis

Usando o Escopo Confiável da Conta

Usando o Escopo Confiável de Tags

Usando o Escopo Confiável Explícito

Usando os Escopos Confiáveis Explícitos de Vários Recursos