I’m currently in need of some clarification for an authentication/overall strategy. First I will describe the use case and then the questions that arise for me.
I want to have a single docker container consisting of an API and a database for each group of users. So for the sake of this example let’s say we have three docker containers A, B and C and three users for every container (A1, A2, A3, B1, B2, ...). Each of these users should only have access to their corresponding API. So e.g. user B1 can only read/write with API B.
The APIs should be consumed with multiple SPA FrontEnd Apps. To not have to log in on each app I want to implement a SSO flow with a single authentication Server. My thought was to let the user log in with the authentication server that responds with a jwt token (access and refresh) with the unique username in the payload. So on every request to an API Gateway that routes the user to the correct API (e.g. A1 -> A), the user sends the access token. The API then makes a request to the Authentication Server to verify the correctness of the jwt. If that‘s successful the API can log in the user with the specified username (because it also has a database entry of this unique user) over a remote user backend for example. This way if the routing or anything would go wrong the access token would be verified by the Authentication Server but the user A could not be logged into API B because there‘s no user with that name in the database of API B. The remote user header could also not be tempered with because every malicious request that sets this header would be prefixed with HTTP_.
Is this even a secure/feasible authentication/authorization flow?
Is there any default strategy for a use case like this (oidc?)?
How do I safely store access/refresh tokens? Refresh token in a httpOnly cookie and the Short lived Access Token in-Memory of the Browser with a WebWorker or with Private static fields?
Any possible obvious attack vectors?