-
Notifications
You must be signed in to change notification settings - Fork 452
Closed
Labels
Description
Checklist
- I have looked into the Readme, Examples, and FAQ and have not found a suitable solution or answer.
- I have looked into the API documentation and have not found a suitable solution or answer.
- I have searched the issues and have not found a suitable solution or answer.
- I have searched the Auth0 Community forums and have not found a suitable solution or answer.
- I agree to the terms within the Auth0 Code of Conduct.
Describe the problem you'd like to have solved
Beta v4 integration looks great! I helped a Convex customer set it up with Convex so we needed an ID token, the one the useUser() claims are from. I added the second argument of async beforeSessionSaved(session, idToken) to the object returned from that callback to make it available, then used useUser to get it. This solution was indirect so something more obvious could be useful.
Describe the ideal solution
If getAccessToken() took an argument for also returning the ID token or there were a new getIdentityToken() that'd be convenient.
Alternatives and current workarounds
Currently I'm recommending using getAccessToken for the side effect of updating the token, which works because fetchAccessToken is rerun when its identity changes.
const { user, isLoading } = useUser();
const idToken = user?.idToken;
const fetchAccessToken = useCallback(async () => {
try {
// maybe the side effect of getAccessToken
// will include updating the idToken?
void (await getAccessToken());
return idToken;
} catch {
return null;
}
}, [getAccessToken, idToken]);and adding the idToken to the user object.
async beforeSessionSaved(session, idToken) {
return {
// Spread existing session properties to preserve original data
...session,
user: {
// Spread existing user properties
...session.user,
// Raw identity token
idToken,
},
};
},
Additional context
No response
Reactions are currently unavailable