Page Comparison

...

The Client application is impersonating a User1 which is a member of 2 3 groups. Each of these groups has access to one server the respective application that should be accessed by the Client1 applicationaccessible 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.If Client1 application is using the token to access to itself then User1 account should be a member of the group which is allowed to access the application.

Configuration

Prerequisites:

1. Exist in SSO:

   1. Site Example

   ,

   1. ;

   2. OAuth 2.0 applications: Client1, Server1, Server2

   , user account User1 and groups

   1. ;

   2. Groups: ClientGroup, Group1, Group2

   exist in SSO.

   1. ;

   2. 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": "openid Server1 Server2"
...

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

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

...

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

2. Add this method to site Example.

3. Allow the 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 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.

...