...

The response contains an access token, its type and expiration. Refresh token should shall not be included even if a refresh token table is configured for the client.

There are two main use cases for Client Credentials Grant in SSO:

• Single application use case: token grants access to the application itself;

• Authorized access use case: token grants access to a number of server applications according to the service user rights (group membership, authentication method allowed for service user account)and requested scope.

Single application use case

...

In a single application use case a token grants access to only application itself. There is no authorization for this case.

...

Configuration

Client Credentials Grant can be configured either with SSO Management UI or SSO Management API. This instruction covers the UI. Refer to Configuring impersonation with Management API - SSO for API instructions.

Prerequisites:

1. Site Example, OAuth 2.0 application Client1 and group Group1 exist in SSO.

2. Application Client1 has client_credentials grant type in its metadata:

   Code Block
   language json
   ... "grant_types": [ "client_credentials" ] ...

...

The Client application is impersonating a User1 which is a member of 3 groups. Each of these groups has access to the respective application that should be accessible with Client1 application’s client credentials. Authorization policies that can be configured for server applications are omitted from the configuration example as it is not mandatory.

Configuration

Client Credentials Grant can be configured either with SSO Management UI or Management API - SSO. This instruction covers the UI. Refer to Configuring impersonation with Management API - SSO for API instructions.

Prerequisites:

1. Exist in SSO:

   1. Site Example;

   2. OAuth 2.0 applications: Client1, Server1, Server2;

   3. Groups: ClientGroup, Group1, Group2;

   4. User account User1

2. Application Client1 has client_credentials grant type and client IDs of server applications in its metadata (other scopes are also allowed, e.g. openid):

...
 "grant_types": [
    "client_credentials"
  ],
  "scope": "Server1 Server2"
...

3. Server applications does do not have any grant types or scopes:

   Code Block
   language json
   ... "grant_types": [], "scope": "" ...

...

1. Create and enable authentication method AuthMethod as described in ​OAuth 2.0 Client Credentials Grant authentication method - SSO

2. Add this method to site Example.

3. Allow the AuthMethod method for applications: Client1, Server1 and Server2.

4. Allow ClientGroup to access Client1 application.

5. Allow Group1 to access application Server1.

6. Allow Group2 to access application Server2.

7. Allow the AuthMethod method for user account User1.

8. Make User1 a member of ClientGroup, Group1 and Group2.

9. Add Client1 application to the list of applications impersonating an account User1.

...

Now it should be is possible to get the token for Server1 or Server2 with Client1 application credentials. Scope defines the intended audience for the access token and may also include openid:

POST {{baseUrl}}/uas/oauth2/token
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials&scope=Server2&client_id=Client1&client_secret=secret

Then the token can be introspected by the authorized Server2 application:

POST {{baseUrl}}/uas/oauth2/introspection
Authorization: Basic Server2 secret
Content-Type: application/x-www-form-urlencoded

token={{accessToken}}

...

Also user information can be obtained using the received token:

POST {{baseUrl}}/uas/oauth2/userinfo
Authorization: Bearer {{accessToken}}

...