API to update id_token custom claims

[burkov]

Storing mutable information in JWT custom claims now makes no sense as far there is no way to update it. For example, we want to store user's email in email claim.

1. OIDC client authorizes with offline access at Hydra
2. User changes email in his profile
3. Refreshing ID token gives the same old claims with outdated email. There is no way to tell Hydra that user's email has been changed

It would be nice to have an admin API call like "update JWT claims for all sessions of given sub" Something like PUT /oauth2/auth/sessions/id_token?subject=blah with an updated JWT claims as a request body

[aeneasr]

I believe we have had an issue tracking such a feature but couldn’t find it right now. One problem with OIDC is that - usually - data is not kept in sync. For example, when you use „sign in with google“ what usually happens is that your app creates a profile based on information from google and usually also allows users to set the email, password, address, … independently from Google which breaks the „sync“ between Google data and yours.

In Ory Hydra what you do is that you initiate another OAuth2 flow with the „openid“ scope in order to get a new ID Token. If you do that, your consent app has the chance to update the data for the ID Token claims. I’m right now not sure if we support refreshing ID Tokens (using a refresh token and nothing else) without such a flow which would potentially introduce the need for a solution following your suggestion.

[burkov]

1. The situation with out-of-sync accounts on different sites you've described above is not related in any sense to the topic. I don't expect Google to notify me on every JWT data change (push model)
2. But if Google gives me a refresh token to fetch a new id_token on demand I expect every new id_token to contain recent (fresh) user data, not historical user data I fetched on initial OAuth procedure completion (pull model)
3. Hydra DO support refreshing of id_token (I've just checked it, new id_token has different jti, exp, iat, etc with the same custom claims as the first issued token)
4. Moreover we rely heavily on that behavior, is it quite handy. But it is a bit lame right now because there is no way to update custom claims in id_token and that makes id_token not usable for user information transfer (mutable data in claims is actual only on initial id_token obtain, if you refresh id_token you can't trust mutable custom claims in it as they can be outdated)

[aeneasr]

I see, I thought we had an issue tracking this request but apparently not so. I agree that the ID Token should carry up-to-date information about the user, as should the /userinfo endpoint. I think an endpoint to update an existing consent flow could be used here. Updating the session info based on the sub field is probably the best idea!

Let's get this into a proposal form for an API suggestion and following that into a PR submission! :))

[burkov]

hm, I have almost no experience in Golang, but I will try 🤔

[aeneasr]

Nice! It would already be helpful to have the proposal for the API in issue form - someone else could then also pick it up implementation wise :)

[wxdao]

Hi I just filed an issue #2570 about letting custom code to be run on token refresh flow.

[vinckr]

This feature in the form of a token refresh hook has been added 👍
Endpoint which will be called during refresh_token grant to retrieve updated token claims. Hook will be noop if not configured. #2649

[synclpz]

Why did you decide to make it a hook and not a reverse behaviour with a PUT endpoint on Hydra? The hook seems to become a bottleneck or even a failure point in case of decent load on refreshing tokens.

Anyway how would Hydra handle an unavailability or high latency on the hook?