OpenID to allow access to different applications.

Hey Freddy,

TLDR;

I don’t think what you are asking is possible. In your scenario application A would have to take on the role of storing which users are able to access B and C meaning you would have to implement what IAM does for Thinkwise applications on your own. Consider registering OAuth/OpenID clients for B and C in IAM as well and configure custom resources to return additional claims with which you can determine if a user is actually authorized to access the resource server instead.

Full answer

I might not understand your example completely so I’m going to make some assumptions and give some background information about OpenID Connect in my answer.

OAuth 2.0 has defined a concept for:

• Authorization servers
  • These handle the authentication of the user and return access tokens that can be used to make requests to resource servers.
• Resource servers
  • These are the actual applications/APIs that validate/consume the access token and allow/deny access based on that.
  • Validation might include a check if the (assuming it is) JWT token is signed by an authorization server that the resource server trusts etc.
  • Claims within the JWT token tell the resource server what this “user” has access to parts of the API using the token.

OpenID Connect is an extra layer on top of OAuth 2.0 that basically standardizes some parts that are left up to the implementation when using “raw” OAuth 2.0. Part of this is defining an extra JWT token called the ID token and some other stuff when acting as the authorization server. E.g. it defines some pre-defined scopes, such as “openid” that can be requested.

When using the Thinkwise platform “normally” Indicium and IAM combined act as both the authorization (users stored in IAM) and resource server (applications synchronized to IAM).

There is currently no way to “scope down” access to an application within IAM. This is something we are looking into but currently the roles mechanism within IAM is what is authorizing application access after a session has been started.

For external resource servers, which I assume A, B and C are in your example, there is currently also no way to directly define scopes (besides the OpenID Connect ones) on just the initial access token.

What you can do however is create “Custom resources” in IAM and assign them to a “Client application”. In these custom resources you can define additional claims which you can assign a value per user or user group. The catch here is that these are also considered user info claims. Which means the claim values must be retrieved from the user info endpoint defined by the OpenID Connect well-known endpoints document (available at /.well-known/openid-configuration in Indicium) using the access token that was granted on login.

There is an option to always do this for a client by enabling the “Always include user info in token” setting.

So lets take a look at the example you’ve mentioned and see if I understood what you meant to convey.

• There is an IAM + Indicium setup somewhere acting as the authorization server.
• Applications A, B and C are resource servers that are “external”, meaning they are not Thinkwise applications synced to an IAM.
• Resource server A uses the IAM authorization server as an Identity Provider to provide a way for users to login.
• The authorization server has a client registration for resource server A which uses the “Authorization Code” grant type, allowing the users to login interactively etc.
• The user device, upon successful login, gets the access token which it then uses to make requests to resource server A. This can, for example, be saved as a cookie for the domain resource server A is located at.
• Upon further requests from the user device resource server A now has to, potentially, use the claims it got from the access token to authorize the request within itself.
• Resource servers B and C now want to use resource server A as an authorization server.
• This is where the problem in the scenario start.
• Resource server A must now also implement the authorization server side of OAuth 2.0/OpenID Connect.
• It could still use the IAM as an external Identity Provider as before but there might not be a point anymore to do so.
• E.g. for IAM you could also define some Azure AD/Entra tenant as an external IdP but after logging in through that a user still has to be matched with one that IAM knows about and is configured as “external”.

E.g. consider that a user might already have a session with application A.

• If they try to access resource server B it will try to ask application A if they know who this is. Because A is considered the Identity Provider/authorization server by B.
• Since the user device already has a session for application A, it will not bother asking the IAM authorization server for the user identity and potentially skip the user info step making the custom resources feature useless.
• So application A, as an authorization server either has to:
  • Manage authorization settings for resource servers B and C on its own, include client registrations etc.
  • Or still let IAM manage the users and always request the extra custom resource scope claims for B and C even if they are only logging into A. B and C still require an OAuth client registration in A to attest that it is your server making the call.
  • Detect, somehow, that session doesn’t currently have the required scopes/claims it needs and then tries to attempt to expand the user info for the session using the IAM authorization server. Which may require another login if the session on that server has expired.

I’m not even sure if the last two points are possible at all and A would still need to take care of the access token generation etc. because the IAM authorization server doesn’t actually know about B and C and those in turn cannot trust IAM for claims as the authorization server they have been configured with is A, not IAM.

All of them also require that you have full control over how application A is built.

A much simpler option would be to just have A, B and C all act as resource servers with their own client registration in IAM. You could then define custom resources for each to signal whether a user (group) actually has access to your external application. Assuming of course that you have enough control over A, B and C to validate the claims that get sent back from IAM.

If I misunderstood what you are asking let me know.