Description

According to the RFC 6749 an application (client) owns the credentials and uses them to get an access token from the Authorization Server.

...

• 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 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

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" ] ...

...

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).

...

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.

...

{
  "usn": "Client1",
  "iss": "https://localhost:8443/uas",
  "aud": [
    "Server2",
    "Client1"
  ],
  "exp": 1696336474,
  "iat": 1696333379,
  "auth_time": 1696332874,
  "amr": [
    "https://localhost:8443/uas/saml2/names/ac/client.credentials.1"
  ],
  "azp": "Client1",
  "session_index": "_236ae5a56862435c4f19e6d6b55d90ae97e79df4",
  "client.credentials.1.grant_type": [
    "client_credentials"
  ],
  "client.credentials.1.issuer_dn": [
    "cn=Client1,ou=Example,cn=Ubilogin,dc=test"
  ],
  "client.credentials.1.issuer": [
    "Client1"
  ],
  "client.credentials.1.dn": [
    "cn=User1,ou=Example,cn=Ubilogin,dc=test"
  ],
  "client.credentials.1.ldap": [
    "ldap:///cn=Ubilogin,dc=test"
  ]
}

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., a sub 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).

...