The .well-known/openid-configuration states that it should be possible, however it cannot be configured now.
It would be very nice to be able to have this authentication type.
The .well-known/openid-configuration states that it should be possible, however it cannot be configured now.
It would be very nice to be able to have this authentication type.
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.
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.
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 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 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 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?
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.
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…
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.