I'm building a multi-tenant system that consists of one (SPA) client, calling multiple API's, all under my control.
User authentication is done with OpenID Connect, I'm sending an ID and access token to the client, the client uses the access token to call the API's.
At this stage, the API's know they receive a request from an authenticated user, but they still need to know what that user can do, the Authorization part.
I would like to prevent the scenario where all my API's call a store where authorization data is persisted, it feels like a performance bottleneck, and would tightly couple all my API's.
I would like to keep my OpenID Connect server as decoupled from this specific project as possible, processing only the users's identity and API scope claims. Therefore, putting all authorization-related claims inside the access token seems like the wrong move.
I came up with the following solution:
User navigates to SPA
SPA calls OpenID Connect server, gets an access token with identity info
SPA calls a custom API endpoint, specific for this project, lets call it 'user-info-api'
This API issues a custom JWT token, signed by cert or shared secret
This custom JWT token is appended on every subsequent API request, it contains all info needed to do user authorization in each API, therefore eliminating round trips to the authorization store. The only thing the API's need to do is to verify it's signature
I would like a 2nd opinion on this approach for the following reasons:
- This seems a bit over-engineered
- I'm worried about the increased payload this would bring to each http request.
- I'm wondering if there are standardized approaches tackling this same issue