-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Persist custom JWT properties when refreshing a token #1484
Comments
How about to store custom JWT properties in user.data object and use a lambda function to populate JWT? |
Hi - I'm afraid not. We thought about that as a possible option, but a user can have multiple concurrent sessions and so you can't guarantee which token's data is being stored in the user.data. Thanks for checking though. |
@stuellidge Just to make sure I understand the issue, is this what you are trying to do?
Is that correct? |
@mooreds Hi, picking this for @stuellidge Given we have a function populate(jwt, user, registration) {
// Debug logging
console.debug('JWT Before Lambda Execution');
console.debug(JSON.stringify(jwt));
// This variable is just an example
var passwordlessAuthenticationTypes = ['PASSWORDLESS', 'HYPR'];
// Check to see if we have a `source` property on the JWT, if we login via a passwordless method,
if (!jwt.source && passwordlessAuthenticationTypes.indexOf(jwt.authenticationType) >= 0) {
jwt.source = 'PASSWORDLESS';
}
console.debug('JWT After Lambda Execution');
console.debug(JSON.stringify(jwt));
} When we first login using a passwordless method (in our case {
...,
"exp": 1641913950,
"iat": 1641913050,
"sub": "78c7cbef-dfdc-4403-b77a-e47cf7dae3b4",
"authenticationType": "HYPR",
"source": "PASSWORDLESS",
...
} The For example, when POSTing to the {
"scopes": "offline_access",
"client_id": "clientId",
"client_secret": "clientSecret",
"refresh_token": "<< USER REFRESH TOKEN HERE>>",
"access_token": "<< USER ACCESS TOKEN THAT HAS/ABOUT TO EXPIRE >>",
"grant_type": "refresh_token"
} This then invokes our lambda shown above, but the Our code also will not continue to work, as the If we were able to have access to the previous/existing/original // We add a `originalJwt` to the `populate` method signature, which gives us access to the JSON of the JWT we refreshed (optional - not always going to be provided)
function populate(jwt, user, registration, originalJwt) {
if (!jwt.source && originalJwt && originalJwt.source) {
jwt.source = originalJwt.source;
}
} This also relates to #1484 and #1491 but I feel as if having the ability to preserve claims/properties through refreshes is beneficial to integration developers looking to preserve some unique state from the initial JWT issue. For example, as stated, the |
Thanks for the additional explanation @CaLxCyMru . It sounds like there are two approaches that might solve the issues:
|
This could work. One possible issue may be that if a custom claim is based upon user data, or user state, the claim may be "stale" so to speak if we just copy it along. Maybe this is buyer beware if you enable this feature.
If you were to present the existing JWT during the refresh request (we don't persist this), I suppose it is plausible that we could provide that as an argument to a populate lambda. This may be risky because in most cases I would assume the JWT will be expired. If it is expired, I don't think we would want to trust it or even present it to a JWT populate because we would be implying trust. We'd also need to see how to add this capability to both the JWT Refresh API (easy) and the Token endpoint to support the same capability through the Refresh grant (more difficult). |
Thanks for the consideration @robotdan @mooreds and for the explanation @CaLxCyMru |
If we were to add this capability, not sure how we know what is "custom". A simple approach would be to take the object keyset prior to the lambda, and then any new keys after the lambda are considered "custom" (not added by FusionAuth) and we would store them away for use when we issue another JWT using a refresh token. If we were to add claims such as |
In cognito, custom attributes are always prefixed with |
Hello @mooreds, this is exactly my issue. Why would the refresh token not have the claims? Any solution? |
Persist custom JWT properties when refreshing a token
Problem
The Populate JWT lambda makes it possible to set custom JWT properties on a token. For some (for example, capturing the original login instant or preserving the original authentication type) it is not possible to define them on a subsequent token refresh because the original token is not available.
Solution
We would like the ability to preserve custom JWT properties between refreshed tokens
Alternatives/workarounds
An alternative (not available) would be to provide the previous token during a refresh JWT Populate so that we could copy properties across.
Additional context
N/A
Related
Community guidelines
All issues filed in this repository must abide by the FusionAuth community guidelines.
How to vote
Please give us a thumbs up or thumbs down as a reaction to help us prioritize this feature. Feel free to comment if you have a particular need or comment on how this feature should work.
The text was updated successfully, but these errors were encountered: