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
/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/userinfopara 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).
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.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::allna solicitação. Um erro de escopo inválido será retornado se você tentar incluir o escopourn:opc:resource:consumer::alle outro escopo na mesma solicitação, comourn:opc:idm:__myscopes__. -
A solicitação de um token de acesso usando o escopo
urn:opc:resource:consumer::allnão retorna um token de acesso que fornece acesso às APIs de administrador de domínios de identidade. Você deve continuar usando o escopourn: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
trustScopedeExplicité 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çãoAllouTagged, você deve atualizar o aplicativo cliente com o valortrustScopedeAllouTags. - 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 escopourn: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.
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:
-
Designe o valor de
Accountao parâmetrotrustScopepara o aplicativo cliente confiável apropriado.Observação
O atributotrustScopedeAccounté nomeado Todos 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úblicourn:opc:resource:scope:accounte o escopourn: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.
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
urn:opc:resource:consumer::all, você também pode especificar os seguintes escopos detalhados:urn:opc:resource:consumer:paas::readurn:opc:resource:consumer:paas:stack::allurn:opc:resource:consumer:paas:analytics::read
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
}
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.
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:
-
Designe o valor de
Tagsao parâmetrotrustScopepara permitir que o aplicativo cliente acesse tags de outros aplicativos.Observação
O atributotrustScopedeTagsé nomeado Marcado com Tag na Console do domínio de identidades. -
Defina o par
key:valuepara o parâmetroAllowedTags.Observação
Essas etapas pressupõem que o Aplicativo de Recurso apropriado tenha definido pareskey:valuepara o atributoTagse que pelo menos um parkey:valueda lista do atributoallowedTagsdo Aplicativo Cliente corresponda a um parkey:valuedo atributoTagsdo 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-alvourn:opc:resource:scope:tag=<base64 encoded JSON>e o escopourn:opc:resource:consumer::all, que dá acesso aos Aplicativos de Recursos que têm tags que correspondem às tags permitidas especificadas no Aplicativo Cliente.
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
urn:opc:resource:consumer::all, você também pode especificar os seguintes escopos detalhados:urn:opc:resource:consumer:paas::readurn:opc:resource:consumer:paas:stack::allurn:opc:resource:consumer:paas:analytics::read
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
}
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.
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.
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.
- Especifique o escopo recém-definido,
urn:opc:resource:multiresourcescopena 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.
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"
}