App-scoped id_token / local storage entries

We have two applications A and B running on the same server.

The id_token of each application represents a different aspect of the same user. They should not be used interchangeably.

However, when a user opens both applications in the same browser, id_token of application A might be send to application B (which leads to failure).

We cannot use sub-domains (as the applications are embedded into another application, which runs on a single domain).

It would help if local storage entries such as id_token, would be scoped, like this:

appA.id_token
appA.id_token_expiration
...
appB.id_token
appB.id_token_expiration
...

This would require a configuration for the scope / prefix / app name and some sort of indirection when accessing Storage.

We looked into the uaa-authentication-client code and came to the conclusion, that any effort from our side would be hacky and / or require rewriting larger parts of the client.

What would it entail for the A12-team to make this feature part of the product?

Hello @anon67142020 ,

Thanks for the question. Please aware of the meaning of Applications which you’re mentioning here is about Clients within a Realm.

Users are bound to Realm but not bound to Clients. That means a user in a Realm are able to login in any Clients/Application which are belonging to that Realm.

Authorization for User in different Clients.

  • You should be able to configure the Client Role for the user in specific Client.
  • Create your own implementation of com.mgmtp.a12.uaa.authentication.oauth.OauthClaimsExtractor which will extract the information inside JWT token
  • Read/Extract Client Role information in JWT token and return a different UserDetails in the end for different Clients.

By following that approach

  • you’re free to create an UserDetails for the same user but has different roles in different Clients/Applications.
  • Using UAA APIs com.mgmtp.a12.uaa.authentication.oauth.OauthClaimsExtractor so it’s not a hack at all.

I hope this would help.