Using the Account Trust Scope

The Account trust scope allows a trusted or confidential client application to acquire an access token that gives access to any of the services that are in the same domain without requiring explicit association with the target services.

Note:

The option to define the trustScope parameter is available to only trusted and confidential client applications. The option is not available to public client applications.

To use the Account trust scope:

  1. Assign the value of Account to the trustScope parameter for the appropriate trusted client application.

    Note:

    The trustScope attribute of Account is named All in the Oracle Identity Cloud Service administrative console.
    A portion of an example request with a red arrow pointing to the trustScope parameter.

  2. Request an access token using the trusted or confidential client and request the scope urn:opc:resource:consumer::all. The access token in the response contains the audience urn:opc:resource:scope:account and the scope urn:opc:resource:consumer::all, which gives access to any of the services that are in the same domain without requiring explicit association with the target services.

Note:

The requested scope should always exist and match, either directly or hierarchically, the client's defined allowed scopes to allow the client access to the resource.

Using Fine-Grained Scopes

In addition to using the urn:opc:resource:consumer::all scope, you can also specify the following fine-grained scopes:

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

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

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

The requested scope from the client app must match, either directly or hierarchically, at least one of the client's allowed scopes to allow the client access to the resource. For example, a client app uses the urn:opc:resource:consumer:paas:analytics::read scope in its request for access to a resource. If the scope directly matches an allowed scope defined, in the returned access token, the audience is urn:opc:resource:scope:account and the scope is urn:opc:resource:consumer:paas:analytics::read.

If the allowed scope defined by the client is urn:opc:resource:consumer:paas::read, then the client app is allowed to access the resource hierarchically if the client requests one of the following scopes: urn:opc:resource:consumer:paas::read or urn:opc:resource:consumer:paas:analytics::read. However, if the requested scope is urn:opc:resource:consumer:paas:analytics::write, then the client isn't allowed access to the resource, since that isn't one of the allowed scopes defined by the client app.

Request and Response Examples

The following examples show request and response examples for the client credentials and resource owner grant flows.

Client Credentials Flow Request Example

curl -i
-H 'Authorization: Basic TXlUZXN0U2VydmljZV9BUFBJRDoxMGE2ODAwMC03YTYzLTQxNDItODE0Ny03MGNmMGJhMDFkYjg='
-H 'Content-Type: application/x-www-form-urlencoded; charset=utf-8'
--request POST 'https://tenant-base-url/oauth2/v1/token' -d 'grant_type=client_credentials&scope=urn:opc:resource:consumer::all' -k

Response Example

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

Note:

The access token contains the audience urn:opc:resource:scope:account and the scope urn:opc:resource:consumer::all.

Resource Owner Flow Request Example

curl -i
-H 'Authorization: Basic TXlUZXN0U2VydmljZV9BUFBJRDoxMGE2ODAwMC03YTYzLTQxNDItODE0Ny03MGNmMGJhMDFkYjg='
-H 'Content-Type: application/x-www-form-urlencoded; charset=utf-8'
--request POST https://tenant-base-url/oauth2/v1/token' -d 'grant_type=password&scope=urn:opc:resource:consumer::all&username=admin@example.com&password=PasswordExample1' -k

Response Example

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

Request and Response Examples Using a Fully-Qualified Scope

The following examples show request and response examples using a fully-qualified scope.

Request Example

curl -i
-H 'Authorization: Basic TXlUZXN0U2VydmljZV9BUFBJRDoxMGE2ODAwMC03YTYzLTQxNDItODE0Ny03MGNmMGJhMDFkYjg='
-H 'Content-Type: application/x-www-form-urlencoded; charset=utf-8'
--request POST 'https://tenant-base-url/oauth2/v1/token' -d 'grant_type=client_credentials&scope=http://abccorp1.com/scope1'

Response Example

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

Resource Owner Flow Request Example Including the Request for a Refresh Token

To generate a refresh token in addition to the access token, use the scope urn:opc:resource:consumer::all offline_access in the request. 

curl -i
-H 'Authorization: Basic TXlUZXN0U2VydmljZV9BUFBJRDoxMGE2ODAwMC03YTYzLTQxNDItODE0Ny03MGNmMGJhMDFkYjg='
-H 'Content-Type: application/x-www-form-urlencoded; charset=utf-8'
--request POST https://tenant-base-url/oauth2/v1/token' -d 'grant_type=password&scope=urn:opc:resource:consumer::all offline_access&username=admin@example.com&password=PasswordExample1' -k

Response Example

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