Skip to content
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

v4: Bring back the ability to pass refresh: true to getAccessToken #1884

Open
5 tasks done
dkokotov opened this issue Feb 6, 2025 · 3 comments
Open
5 tasks done

v4: Bring back the ability to pass refresh: true to getAccessToken #1884

dkokotov opened this issue Feb 6, 2025 · 3 comments

Comments

@dkokotov
Copy link

dkokotov commented Feb 6, 2025

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

In v3, when calling getAccessToken, it was possible to pass { refresh: true } to force the access token to be refreshed even if it had not yet expired.

This is useful in contexts when you know that something about the user has been updated in auth0 that would cause the access token to be different, and you would like to retrieve an updated token that reflects the changes. An example would be:

  • you use the access token to call an API that checks for certain claims or permissions
  • you've updated the user in auth0 via management api to give the new permissions
  • now you need to refresh the access token so it reflects those new permissions before calling the API.

In v4, I am not seeing this option, or any way of replicating this functionality.

Describe the ideal solution

Re-introduce the optional { refresh?: boolean } parameter to getAccessToken() - if set to true (and refresh token exists) it will always request a new token before returning it, even if current token exists and is not expired.

Alternatives and current workarounds

I haven't found a workaround yet, the relevant code seems to be in get-access-token.ts and there is no way to inject the desired behavior.

Additional context

No response

@dkokotov
Copy link
Author

dkokotov commented Feb 7, 2025

As a followup, I found a workaround for the issue as described above. basically the idea is to update the session to make it look like the token has expired, then call getAccessToken(). this is tacky but it works:

class MyAuth0Client extends Auth0Client {
    async refreshAccessToken(): Promise<{ token: string; expiresAt: number }> {
        const existingSession = await this.getSession();
        if (!existingSession) {
            throw new Error('The user is not authenticated.');
        }

        const sessionToForceTokenRefresh = {
            ...existingSession,
            tokenSet: {
                ...existingSession.tokenSet,
                expiresAt: 0
            }
        } satisfies SessionData;
        await this.updateSession(sessionToForceTokenRefresh);
        return this.getAccessToken();
    }
}

However, there is a new issue. I would also like the user info (as retrieved from the ID token) to be updated. In v3, this happened when the access token was refreshed. However, in v4 this does not seem to happen, and looking at the code, it makes sense: in v3, it parsed out the id token from the oauth endpoint response for token refresh and updated session.user, but in v4 it does not.

Can we bring this back? The motivation is - I display user info like name, email, etc which I get from useUser(). Elsewhere, I have UI to let the user update their email/info. This updates it in auth0 via management API, but now I need some way to update the user returned from useUser() to match.

I could probably make a workaround, where I also update the email/name/etc in the session directly when the user uses the "update email/name/etc" functionality. and this may even be better as an "optimistic update". but it still feels like refreshing the access token should also update the user info from the id token (or at least there should be an option to do make it so)

@RigoMiranda
Copy link

RigoMiranda commented Feb 7, 2025

I am migrating an application from Next14 with Auth0 3.6.0. to Next 15 and V4.0.0-beta.14. I am having a similar issue.

Issue

When we create accounts with Username and Password, by default email_verified: false. When the users get the verification email and press the link the email_verified changes to true but when I run the getAccessToken, I still get email_verified: false. If I force log out and log in, then I get the correct value for email_verified. Based on the documentation https://www.npmjs.com/package/@auth0/nextjs-auth0/v/4.0.0-beta.14, there is no way to force refresh the token with V4.

V3

When using V3, I have the code below in app/api/auth/[auth].ts, and it works as expected, it returns the new user profile data and update the token in the browser as well.

'update-session': handleProfile({ refetch: true }),
  logout: handleLogout({
    returnTo: '/',
  }),

@pkat
Copy link

pkat commented Feb 7, 2025

I would be interested in a solution for this as well. I haven't yet started the migration to v4 yet, but in current v3, I am doing something similar for email_verified except with updating profile.

/api/auth/[route].ts:

  'update-me': async function updateSession(req: NextApiRequest, res: NextApiResponse) {
    return handleMeProfile(req, res, true)
  },

and on my /auth/verified page along with useUser:

    <UserProvider profileUrl="/api/auth/update-me">
       <!--children here-->
    </UserProvider>

I would hope there is a way to force a refresh of the token or at least the accessible user profile info to attain an up to date value for email_verified.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants