...
Now it is possible to get the token with Client1 application credentials. Refer to Client authentication - SSO for more authentication options:
| Code Block |
|---|
POST {{baseUrl}}/uas/oauth2/token
Content-Type: application/x-www-form-urlencoded
grant_type=client_credentials&scope=oidc&client_id=Client1&client_secret=secret |
...
For example Client1 could be a command line script, Server1 is SSO Management API and Server2 is CustomerID API.e
The configuration with 2 two server applications shown below.
| Gliffy | |||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...
|
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.
...
Only one grant type client_credentials must be configured in client’s application metadata grant_types. There are no grant_types configured for server applications (authorized access use case).
Server application scopes should be defined in the client application’s metadata. Avoid empty scope metadata field since it will allow all audiences.
Authorized Access configuration case must be used with caution. Avoid complicated configurations. Design access controls so that unintentional impersonation is not possible. This could happen if, on the server application, there are other methods enabled in addition to the client credentials method which is often the case with real world scenario other authentication methods scenarios in SSO.