...

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

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 in SSO.