Hi all, I'm looking how can I reduce amount of cal...
# general
s
Hi all, I'm looking how can I reduce amount of calls to whoami. And in the docs there is suggestion to use JWT, and it looks like Oathkeeper can convert sessions to JWT.
Convert sessions to JWTs on your entry point. You then have the option to add caching to further reduce the number of API calls made. More information on this approach is available in the section below.
https://www.ory.sh/docs/kratos/session-management/overview#use-ory-oathkeeper-to-convert-sessions-to-jwts I don't get how that will allow to cache anything? If oathkeeper does not do some session-cookie caching it merely converts cookie to jwt on each request, and this shifts session validation logic from backend to oathkeeper. But only real option is still to create JWTs on the frontend for frequent operations?
b
The idea is that you can generate a single JWT per request in a distributed system, where each microservice would have to make its own whoami call to actually verify the user's identity, leading to an exponential growth in whoami requests per service. Instead, you generate the JWT on ingress, and pass that to your services, each of which can then validate the (short-lived) JWT. In what context are you making the whoami requests? And why do you want to reduce the number of requests you're making?
s
Makes sense, maybe that can be more explicit in the docs. I’ve hoped that oath keeper does micro caching of some sort like "I've just authenticated this session cookie just a 30seconds ago, I can reuse last toSession data". I'm currently have a single service with a middleware that basically calls toSession on every authenticated action . Which feels wildly ineffective to me, not to mention additional latency for network roundtrip to kratos. Being a chat app, whoami/toSession is basically called on every sent message that can be a lot. So issuing JWT on the frontend and using them for frequent actions seems like a proper solution.
s
feels wildly ineffective
This is required though for proper session invalidation. With that in mind, there are definitely use-cases where it is prohibitive to call whoami on every single call (most cases should be fine, and we have edge caching on ory network to solve that). Regardless, we also have a session-to-JWT feature: https://www.ory.sh/docs/identities/session-to-jwt-cors
Keeping the JWT valid only for a couple seconds is key for proper invalidation though, so it should not be one JWT valid for the whole session.
s
Thanks, this is more in line with what I imagined. From the docs it seemed that something like that is implemented on the Oathkeeper side.
s
Oathkeeper can also do that, but it is meant rather for the use-case Jonas mentioned.