Reducing Kratos requests in microservice architecture

[eriklott]

Is there a way to reduce the number of requests made to Kratos in a microservice architecture?

Here is the scenario: Let's say that I have 5 services, plus Kratos, running on Google Cloud Run or Heroku (API gateway not possible). Each service is hosted on a unique subdomain with a common TLD. Kratos will be providing authentication to the other services, and will have the session cookie configured to be shared across the common TLD (all apps will receive Kratos cookie on each api request).

If I understand the correctly, each time a request is made to one of the services, that service will then need to make an additional request to the Kratos service "/whoami" endpoint to authenticate the incoming session cookie. Is there a way to avoid this chatter? The Kratos service will be receiving 5 times the number of requests as most services...

If the session cookie is pass by value, could the work to decrypt a session cookie and retrieve its data be done directly on each service via a shared symmetrical key or asymmetrical key (i.e kratos client package), rather than making an additional network call to Kratos?

[vinckr]

As far as I am aware this is not supported out of the box right now, maybe @Benehiko can comment on this 😉

[Benehiko]

Hi @eriklott

@vinckr is correct, there is nothing out of the box that would be able to reduce this.
You have a couple of options which would require some work on your side:

1. Decrypt the cookie yourself (this would mean implementing on your service what Kratos already does in /sessions/whoami)
2. Convert the cookie to a JWT which you verify in your services. (could be done in oathkeeper mutators)

With the first option you can look at what Kratos does in its whoami handler found here and here. This would then mean sharing the cookie secrets - config here - with your services.

With the second option you can use oathkeeper mutators found here

[eriklott]

Thanks for getting back. I've considered duplicating the Kratos code as well, but in the end, I'd rather use a supported solution. It would be great to be able to decrypt the session cookie in the client and avoid the unnecessary round trips on the network, but I realize this is additional work to implement when the clients are auto-generated.

I'll have a look at the oathkeeper mutators. Thanks again - Kratos is a great product!

[abhinav-ameyo]

Hello @Benehiko,
I have a query in the above solution, suppose we are using Kratos and oathkeeper, as per my understanding oathkeeper performs four steps https://www.ory.sh/oathkeeper/docs/#decision-engine Access Rule Matching > Authentication > Authorization > Mutation.
For our case, we are interested in Authentication and Mutation. So Authentication will make a request to the session store,
I also looked at https://www.ory.sh/oathkeeper/docs/pipeline/authn , but here oathkeeper will need to validate the session to "check_session_url" (in case of ORY kratos it will be /whoami endpoint). If success then the mutator will do transformation and create a JWT and append it to request to our server.

• Therefore every request is going from the Authentication step resulting in more network requests.
• Can we bypass the Authentication step? if yes, when the user is logged out or the user session is revoked in Kratos, how the oathkeeper will invalidate the session.

Ultimate goal Is to reduce API requests, as there will be many microservices that will be communicating with each other.