Expose ID token more simply

[thomasballinger]

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

[guabu]

Thanks for the feedback @thomasballinger! Initially we wanted to avoid storing the ID token on the session by default to avoid exceeding the browsers' cookie size limits — instead we only store a subset of the claims which can be modified using the beforeSessionSaved hook as you shared.

We'll look into offering a simpler (opt-in) way to store and retrieve the access token.