Hi everyone :slightly_smiling_face: I'm setting up...
# talk-kratos
c
Hi everyone 🙂 I'm setting up Kratos (behind Oathkeeper) for use with Hasura. I have my own 
users
 table in the db which is used for permissions, and the JWT that Hasura reads needs to include the id of the user (in some custom claims). The 
id_token
 mutator in Kratos only has access to the 
identity
 table's id created by Kratos, so I need to somehow add the corresponding user's id to be able to add it to the JWT claims. I was considering putting the user id in the traits, but it's kind of sensitive and - more importantly - it cannot be allowed to be changed by the user. I see three options: 1. add the user id to the identity somehow (traits don't seem to be an option) 2. load the user id when logging in and add it to the session data that the mutator has access to, this could be a hook, but I don't know if the result of the
login.after
hook is accessible somehow? 3. read the user id from hasura in the mutator (this seems the less optimal option as that would make a request to hasura on every mutator execution) Any advice is greatly appreciated, thank you! (the solution to this might be through Oathkeeper, which would be fine)
m
As I mentioned, we might be able to use hooks for this. I think 2. sounds like the best option right now. We have an open RFC for hidden/immutable traits as well. fyi @User you reached out at the perfect time 🙂
I will see to do some testing on my own next week 👍
❤️ 1
a
Ha! Great! I’ll be watching this for sure then. One feature from the Hasura side that helps handle some edge cases like this is the webhook auth method, where you can run some arbitrary logic with each request to Hasura (ie, validating the Kratos token, map it to Hasura’s preferred shape, and return)
In this specific case, since they’re sharing a DB, you can just run your transformation on the request in the handler instead of needing to re-validate against Kratos since you already have the JWT.
c
@User Right, that sounds like another option. It does however have the disadvantage of having to call that webhook on every single request, and the id that it needs will never change, so it would feel nicer to do it either once per session or even better once per registration. @User Yeah I checked out the traits issue earlier, and that would be the perfect solution, since what I need is basically just to store one piece of extra info on the identity, that never changes and is not accessible for the user. As for option 2, can the result of the
login.after
hook be used by the mutator somehow? It seems a bit tricky because the hook is a Kratos thing and the mutator is on Oathkeeper side.