I have the following architecture for accessing a REST service that requires authentication:
- Oidc token flow managed at the client
- Access token verified at the server in the auth service (proxied by the api gateway), exchanged for a jwt that contains authorisation information about the user.
- The resource is accessed
In the current model, every request needs to verify the access token (which is normal), but also needs to retrieve the authorization information on every request, which I don't feel is ok.
The jwt used in this model is only for internal use at the server cluster, as there really is no need to send it back tot the client. Also generating a jwt on every request doesn't feel quite right.
Storing the jwt in a server store (cache / database) is something I don't feel is right with this model, because this makes the system stateful again (in case of multiple api gateways, there is need again for sticky sessions, synchronisation etc). Hence this doesn't offer a solution.
One possible solution would be that authorization is not checked upfront along with the authentication (i.e. verification) process, but only depending on the requested route / action. I don't particularly like this, as this requires back and forth messaging when a protected resource is accessed. It doesn't smell like clean architecture.
What is the advised way to go about this?
Related, I wondered if it is enough to perform authentication in the api gateway. These microservices work independently, and I feel a bit uncomfortable that the api gateway grants all access while keeping the underlying services 'dumb'. Is this a misplaced sense of paranoia?