Enriching JWT after OpenID Connect flow

Question

I am struggling to find a good solution for authorization of users after they were properly authenticated through an oidc flow. Let's assume the following setup:

• An angular SPA is interacting with several microservices.
• It's important to note that those microservices support multi tenancy, depending on the url being called from outside (customer1.myapp.com), the request is done in a specific tenant (let's say tenantId=42). This is applied as a filter to all database requests. Besides this, the tenant id is opaque to the microservices. After this determination, a request being handled cannot break out of it's tenant.
• one service is responsible for maintaining some form of organisation structure, like employees belonging to groups. Lets call it the master data service.
• others might authorize access to resources based on the membership to a group
• authentication is done by Keycloak (with social identity providers in place). Keycloak is not tenant aware, you are the same identity, no matter with what tenant you interoperate. Keycloak cannot be used to model the group membership, because you can be member of different groups depending on the tenant you are interacting with

My first approach was:

• The angular SPA gets an access token from keycloak using the oidc code or implicit flow
• then, the anular SPA is calling the master data service to exchange the keycloak access token (only providing the global identity) for a tenant related access token also containing the group memberships
• the exchanged token is used from now on

However, this feels fishy. While it worked for angular, I was unable to make it work with swagger for example. Other clients (we have a command line interface for imports and stuff) will also have to implement this strange additional step on top of using an oidc-lib off the shelve.

Am I on the right track? Or should I ask the master data service every time whether the request's identity belongs to some group? Right now, the services are not calling each other but just communicating through an message bus.

Answer 1

... then, the Angular SPA is calling the master data service to exchange the Keycloak access token (only providing the global identity) for a tenant-related access token also containing the group memberships

Well, this is how some social login works. Is not that rare.

Say our SPA start the auth dance, it gets an ID token from the 3rd party service and, immediately, pushes it (upstream) to the backend. Then, the backend sends it back to the 3rd party service for validation and, if the 3rd party does respond OK, our backend generates the access token which encodes authentication (user/account/tenancy) and authorization (grants, privileges, roles, ACLS, etc) among other things.

However, this feels fishy. While it worked for angular, I was unable to make it work with swagger for example.

This's a good reason for you to support different auth protocols or schemas. Some protocols work best when there must be human interaction. For example OAuth. Others don't.

Process-to-process authentications are easier with API Tokens. For example, you could provide your master service with support for API Tokens. API Tokens bound to accounts or groups. Basically, it comes to say that If you have one of these tokens you are already trusted and you don't need to get authenticated. Of course, as with everything in this life, it's not exempt from trade-offs.

Other clients (we have a command-line interface for imports and stuff) will also have to implement this strange additional step on top of using an oidc-lib off the shelve.

Working with some cloud platforms clients (for Linux), I have learnt that command-line applications can be stateful. For example, back in my times working with Bluemix, I first had to do login and then choose a namespace (sort of tenancy) otherwise there was no way to do anything with the client. All the options were stored in hidden files (JSON).

Working with GitLab and Bitbucket I started to love supporting SSH Keys what makes working with command-line applications very smooth.