I'm building a multi-tenant app that has the unusual requirement of allowing tenants to use their own choice of external systems for login/authentication

ie: tenant 1 uses Azure AD, tenant 2 uses Auth0, tenant 3 uses Github etc.

The plan is that the app recognizes the tenant (from the url) and offers the appropriate login link to their identity provider, which on success returns an id_token to the client app.

The app (a spa, so non confidential) then passes the id_token in each request to the API Gateway, which checks the token is valid, then uses the token to look up the users authorization rights in an internal user database. These scopes are then passed to the internal back-end APIs.

I'm aware that id-tokens are for the client and access tokens should be used for authN - but in this case the external identity providers are not aware of the users scopes (readCustomer, writeInvoice etc) so cannot issues an access token containing them.

MY QUESTION is am I potentially making an insecure world of pain for myself - or, under the circumstances, is this a practical solution?

Would it be better to only pass the id_token once to the API Gateway/an internal identity provider controlled by us, then have that return access/refresh tokens from then on?

Is there a better way to achieve these requirements?


1 Answer 1


You can use multiple identity providers for each tenant. However, you are losing the benefit of using JWT by retrieving the scopes from the database. JWT can be verified in memory and the information it contains becomes immediately available to the APIs post verification. Database lookup to retrieve associated scopes is an unnecessary I/O that can be avoided if you pre-configure scopes for your OIDC client at the time of onboarding the tenant. There are OIDC client adapters available to configure the client with the identity provider programmatically.

Once you identify the tenant and access token & ID token are issued, the tenant app should send both of them to the API gateway on every request. The API gateway should verify both of them and if the ID token has expired you can obtain new ID token by using the access token. Then read scopes from the access token and pass ID token and scopes to the internal APIs. Do not forward access token to internal APIs as the authorization of request is being done by the API gateway only.

With the above approach, you don't have to setup your own identity provider as gateway unless you have tenants that do not use external identity providers. A middleware service between your internal APIs and tenant app can also handle authentication and authorization without making database lookup. That middleware can also communicate with your own identity provider when required in the same way it communicates with the externals.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .