Table of Contents | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
|
Description
According to the RFC 6749 an application (client) owns the credentials and uses them to get an access token from the Authorization Server.
...
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
Description
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:
Site Example, OAuth 2.0 application Client1 and group Group1 exist in SSO.
Application Client1 has
client_credentials
grant type in its metadata:Code Block language json ... "grant_types": [ "client_credentials" ] ...
The following steps are required to configure single application access:
1. Create and enable ClientCredentialsMethod authentication method as described in OAuth 2.0 Client Credentials Grant authentication method - SSO
Add this ClientCredentialsMethod method to site Example.
Allow the ClientCredentialsMethod method for application Client1
Allow the ClientCredentialsMethod method for group Group1.
Allow Group1 to access application Client1.
Now it should be 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 |
Authorized access use case
Description
In authorized access use case a token issued with client credentials of one application (Client1) can grant access to other applications (Server1…ServerN). Authorization is based on access rights of impersonated user (User1).
For example when a Client1 is 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 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:
...
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:
Exist in SSO:
Site Example;
OAuth 2.0 applications: Client1, Server1, Server2
;
Groups: ClientGroup, Group1, Group2
;
User account User1
Application Client1 has
client_credentials
grant type and client IDs of server applications in its metadata (other scopes are also allowed, e.g.openid
):
Code Block | ||
---|---|---|
| ||
...
"grant_types": [
"client_credentials"
],
"scope": "openid Server1 Server2"
... |
Server applications does do not have any grant types or scopes:
Code Block language json ... "grant_types": [], "scope": "" ...
...
Create and enable authentication method ClientCredentialsMethod as described in OAuth 2.0 Client Credentials Grant authentication method - SSO
Add this ClientCredentialsMethod method to site Example.
Allow the ClientCredentialsMethod method for applications: Client1, Server1 and Server2.
Allow ClientGroup to access Client1 application.
Allow Group1 to access application Server1.
Allow Group2 to access application Server2.
Allow the ClientCredentialsMethod method for user account User1.
Make User1 a member of ClientGroup, Group1 and Group2.
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
:
Code Block | ||
---|---|---|
| ||
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:
Code Block | ||
---|---|---|
| ||
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:
Code Block |
---|
POST {{baseUrl}}/uas/oauth2/userinfo Authorization: Bearer {{accessToken}} |
Expand | |||||
---|---|---|---|---|---|
| |||||
|
Security risk and mitigation
...
Client Impersonating Resource Owner
As described in OAuth 2.0 Security Best Current Practice there is a risk of mixing client and resource owner identity since SSO allows clients to choose its own client_id during registration:
Resource servers may make access control decisions based on the identity of a resource owner for which an access token was issued, or based on the identity of a client in the client credentials grant. If both options are possible, depending on the details of the implementation, a client's identity may be mistaken for the identity of a resource owner. For example, if a client is able to choose its own
client_id
during registration with the authorization server, a malicious client may set it to a value identifying an end-user (e.g., asub
value if OpenID Connect is used). If the resource server cannot properly distinguish between access tokens issued to clients and access tokens issued to end-users, the client may then be able to access resource of the end-user.
Risk mitigation
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 other authentication methods scenarios in SSO.