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

[GitNimay]

Your impression is close, but I would phrase it slightly differently: Kratos traits are not automatically propagated into a Hydra access token just because Hydra used Kratos for login.

Kratos owns the identity and session. Hydra owns the OAuth2 and OIDC tokens. During the login and consent flow, your login or consent app is the bridge between them. If you want Kratos identity traits to appear in the token, the consent app must read the Kratos session or identity, then add the selected values when accepting the Hydra consent request.

For example, in the consent app:

await hydra.acceptOAuth2ConsentRequest({
  consentChallenge,
  acceptOAuth2ConsentRequest: {
    grant_scope: requestedScopes,
    grant_access_token_audience: requestedAudience,
    session: {
      access_token: {
        traits: {
          tenant_id: kratosSession.identity.traits.tenant_id,
          role: kratosSession.identity.traits.role,
        },
      },
      id_token: {
        tenant_id: kratosSession.identity.traits.tenant_id,
      },
    },
  },
});

Then the JWT access token issued by Hydra can contain those custom claims. Oathkeeper’s JWT authenticator can validate that token, and the claims can become part of the Oathkeeper authentication session that your remote JSON authorizer receives.

So the flow is more like this:

Kratos login creates Kratos session
Consent app reads Kratos session and identity traits
Consent app accepts Hydra consent request with selected traits in session.access_token
Hydra issues JWT access token with those custom claims
Client sends access token to Oathkeeper
Oathkeeper validates JWT and passes claims to the remote JSON authorizer
Remote authorizer calls or evaluates Keto using those values

I would avoid having the backend modify or re-sign the Hydra access token after the authorization code exchange. The backend should not “inject” claims into an already issued Hydra token. The cleaner place to add those claims is before token issuance, during Hydra consent acceptance, or through Hydra’s token hook mechanism if you are using that.

Also be careful about putting the whole Kratos traits object into the token. Traits can contain personally identifiable information and can become stale. It is usually better to include only stable authorization attributes, for example:

{
  "tenant_id": "org_123",
  "role": "admin",
  "plan": "enterprise"
}

rather than:

{
  "email": "user@example.com",
  "name": "Example User",
  "phone": "+123456789",
  "address": "..."
}

One more important point: if your authorization decision depends on current data, putting it in a JWT means the decision may be based on stale claims until the token expires. For attributes that change often, the remote JSON authorizer should fetch the latest identity or authorization context server side instead of trusting long lived token claims.

So the answer is:

Kratos does not automatically propagate identity traits into Hydra JWTs.
Hydra can include them only if your consent app or token hook explicitly adds them.
The right place to add them is before Hydra issues the token, not after the token exchange.
Oathkeeper can then validate the JWT and forward those claims to the remote JSON authorizer.