How to add / pass user traits to JWT token ?

[melezhik]

Imaging following ory setup :

• Hydra that uses Kratos as IDP provider, upon successful login, session in Kratos is created and jwt token retuned to a client app ( frontend )

• Oathkeeper is used as an authorization proxy through which all requests to protected resources go.

Oathkeeper has only jwt authenticator enabled and one remote json authorizer enabled which send payload ( http method, uri and user traits extracted from authentication session object ) to keto backed endpoint which performs authorization. Authorization rules are written in terms of user traits.

The question how traits from user ( identity schema ) are propagated to jwt token ? Apparently traits have to be presented in payload send to keto authorization endpoint as Keto permission rules are implemented in terms of those user traits .

My current impression ( I maybe wrong ) backend that receive access token from hydra ( after authorization code exchange ) need somehow inject users traits taken from user Kratos session object into jwt token before it returns it to client app ( front end ).

[SvenPVoigt]

Have you solved this? I am wondering similar: https://github.com/orgs/ory/discussions/147

[vinckr]

Hello @melezhik

You’re right that with the stack you describe nothing “automatically” puts all Kratos traits into the JWT.

The default consent UI only maps email (and some profile fields if the scope is profile) from the Kratos identity into ID token claims.

You have 2 ways to add custom claims into a JWT:

1. If you implement a custom consent app, when accepting consent you can add arbitrary data into session.id_token and session.access_token. Those become claims in the ID/access token (and thus visible to Oathkeeper’s JWT authenticator). [JWT access token custom consent; userinfo custom claims]
2. Alternatively, register an OAuth2 token hook in Hydra. Before tokens are issued, Hydra calls your webhook; your service can fetch traits from Kratos and return modified token session data. [Claims at refresh]

With regards to Oathkeeper + Keto: once you enrich the token via one of the above:

1. Client receives an access token (or ID token) containing trait claims.
2. Oathkeeper’s jwt authenticator validates it, populates AuthenticationSession.Subject and AuthenticationSession.Extra from the token. [Oathkeeper session]
3. Your remote_json authorizer template can read those traits from .Extra and send them to the Keto endpoint in its JSON payload. [remote_json]

Let me know if that helps