✅ In addition to the above question, I would like to validate an AuthN architecture for a microservices setup. My primary goals here are to 1. Establish secure authentication (especially using cookies instead of localstorage) 2. Enforce 0-trust policy 3. Have optimal performance, not stressing any service unnecessarily. The suggested approach would be to run Kratos as an Authn service within the ecosystem. All services are accessible through some public GraphQL API (Proxy). This proxy has a private/public key pair. The public key is distributed to each service (Step 0). Then, a user flow would be as follows: 1. The user logs in (if not already logged in) directly using Kratos 2. The user obtains a session from Kratos 3. The user performs a request to the platform (using the Public GQL API), including the Kratos session (send using cookies) 4. The Public GQL API authenticates the request using Kratos (probably using the

/sessions/whoami

endpoint) 5. Kratos responds with the authentication status of the request 6. The Public GQL API signs the request (the session + identity info returned from Kratos?) with the private key, and forwards the request to the relevant service. E.g. Service 1 a. Service 1 can then authenticate the request by verifying the signature using the public key it retrieved from the Public GQL API during startup 7. If Service 1 needs to call any other service to handle the request (E.g. Service 2), it can just forward the signed request, and Service 2 can verify the signature to authenticate Any thoughts on the correctness and security of this approach? Any feedback (or confirmation) is most welcome! 😊

Not sure how sub-requests gonna work in your case. What if service 1 want to send completely different request(which I think is most common case)? Or what if the request not initiated by user and comes from internal job? Request should be signed then somehow. Does that mean that you will pass private key over the network?

The use case proposed is indeed only showing a request to service that synchronously needs to call another service, but using the same identity that did the original request. (So true authentication here, not authorization, which is handled separately). So there would be no need for resigning the request, we could just pass on the same signature (which would presumably be very short-lived). However it is indeed good to point out that "internal authentication" will also need to be addressed here separately, which can probably rely on the same mechanism that external application will use to authenticate (OIDC of some sorts).