Client credentials openid

The Client Credentials flow allows machine-to-machine authentication and access. This will be quite different from our current Authorization Code flow OpenID apps which allows user authentication and access.

The majority of the current settings for OpenID Apps in IAM will not apply when using the Client Credentials flow.

• First and foremost the UI-flow targeted settings such as logos and translations. 
• The consent settings are not applicable. After all, consent is used in the Authorization Code flow to ask an end user for permission to grant access to information. The same applies for token settings such as profile, e-mail, phone and address and custom configured resources and claims.
• Naturally, Login redirect URLs and Logout redirect URLs are focused around the user flow as well.
• The Offline-access setting, which allows usage of a refresh token, does not apply either for the Client Credentials flow to my knowledge. 
• Furthermore, when using the Client Credentials flow, the ‘API access’ is not optional, it has to be enabled. After all, if you cannot access the API, why bother authenticating at all.

The last bullet point leads to another point - The OpenID App would also require some form of assigned rights and roles for the client. Contrary to the Authorization Code flow where the API access on behalf of the user is granted, the Client Credentials flow is not performed in context of a certain user.

The similarities in configuration between OpenID Apps using Authorization Code and Client Credentials are quite limited.

Should we reuse our current OpenID client registration and point apps supporting Client Credentials flows to a user that should be ‘simulated’ for the API access?

Or should we cut out the middle-man and simply register this as a user in IAM that can authenticate using a secret via a Client Credentials flow?

In short, how to configure the roles for this OpenID App and what should dbo.tsf_user() return?

The former solution sounds easier to implement but I’m very curious to hear your input as you have a  more concrete case in mind.

The case we have in mind is that we have another system (service bus/orchestrator) that sends information to our Thinkwise application. This is currently done via user credentials, security policy of the client requires all connections to use token based authentication. The other system operates fully automated so there is no physical user doing things. 

The current user group configuration would be perfect to use, since that basically does set every rights and roles settings in a correct way. That would suggest that it would be perfect to have a ‘user’ in IAM that can authenticate using a secret via a Client Credentials flow. 

Maybe it would be a nice idea to have the users and the ‘client credentials' users in a separate menu item, so that it is easier to see what client credentials users have been registered and are active. 

The users that can authenticate with this probably also need to have an option to set the timeout so that the system that logs in has to refresh the token. 

Cool, I am curious what solution did you choose?

When API access is checked, a new field will be available which allows administrators to input a user.

This user will then be used for API interaction, and ensure that the OpenID client has limited rights equal to the user.

@Anne Buit @Mark Jongeling I might not understand all the specifics, but for us being able to use Client Credentials would seem to be a safer alternative to the current use of Basic Authentication for external parties connecting to the Thinkwise Platform. Currently we use local IAM username & password for this, we have no OpenID clients configured (instead we use Azure AD as OpenID provider for regular users).

As a result, it seems to me that the below quoted solution would be less configuration for us as customer, while gaining the benefits of the likes of the OpenID Client Credentials flow (short-lived Access tokens). That in turn would mean that the currently chosen solution as explained by @Mark Jongeling is not our preferred solution…

Or should we cut out the middle-man and simply register this as a user in IAM that can authenticate using a secret via a Client Credentials flow?

But again: It might be that I don’t understand all the specifics here…

On a functional level, there is no difference between the various solutions. A ‘service account’ being able to authenticate and obtain an access token using the Client Credentials flow, or the ‘service account’ being appointed as the designated account for an OIDC client app that allows API access via the Client Credentials flow. Both need the same information.

At the end of the day, configuring an OIDC client app in IAM will allow you to use bearer tokens instead of basic authentication. For machine-to-machine, using the appointed user via the client credientials flow. And on behalf of a specific user for external applications (such as postman, insomnia but also other systems using the API) via the grant flow.

Note that this authentication and authorization process is only required when an external application wants access to the API. For regular application usage, there is no need to obtain a bearer token as there is no external application that connects to Indicium on behalf of the end user. After the authentication process (be it username/password, oidc, sspi), a JWT will grant access to the browser.