auth0/auth0-react

That when `Auth0Provider` is created and it calls `client.checkSession()`, the user can pass in `GetTokenSilentlyOptions` to be used in `Flows`

justmobilize opened this issue · 9 comments

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

I am creating some custom Flows in which I need information from the client application. When I call getTokenSilently, I can pass in custom keys. But when Auth0Provider is initiated, it calls checkSession that calls getTokenSilently which I can't control.

Describe the ideal solution

That Auth0ProviderOptions would contain an option to set GetTokenSilentlyOptions to pass to getSession

Alternatives and current workarounds

I haven't found any alternatives yet.

Additional context

No response

As a follow up, I am happy to open this PR

I am also facing this issue right now with another use case.

Thanks for reaching out.

What version of the SDK are u using?

With v2, you can do the following:

<Auth0Provider
  domain={identityProvider.domain}
  clientId={identityProvider.clientId}
  authorizationParams={{
    redirect_uri: window.location.origin,
    foo: 'bar"
  }}
>
</Auth0Provider>

Doing the above ensures foo is set with a value of bar on all requests to /authorize as well as the calls to oauth/token when grant_type is set to refresh_token, including when checkSession is calling getTokenSilently, but also when you call getTokenSilently without setting foo explicitly on that method call.

Would that help?

@frederikprijck - Thank you.

We are currently on v1.9 - we implemented a while ago. This sounds promising.

Is there a way to update the authorizationParams after the <Auth0Provider /> is created? The value we send up will be different based on the logged in user, so need to be able to change it once there is a logout/login.

Not sure i understand what you mean. The question was about checkSession, which typically only hits auth0 before knowing if the user is logged in.

Once that's over, you can pass anything to getTokenSilently and it will override whatever is set in the auth0provider.

With V1, you can try putting the custom param (foo in the example above) on the same level as domain and client id, we moved custom parameters to it's own "authorizationParams" in V2, but the functionaly existed in V1 by putting them on the root of the object.

Regardless, i do recommend updating to V2.

So the issue is that on a hard refresh of the page (or opening in a new tab) after the JWT Token has expired but the user is still logged in, the call to checkSession is made.

I would prefer to clear out the value set on the init, vs a bug creeping up because somewhere we didn't override the value in a call to getTokenSilently.

And yes, will 100% update to the newest version.

You can not update the authorizationParams no.

What you can do, is wrap our call to getTokenSilently to make it so it always uses the correct params based on the logged in user.

Do you happen to have an example of how to wrap that call? Because that would make everything way easier (aka not needing to worry if someone adds a call using that and forgets to pass the params).

What I mean is roll your own hook, or whatever solution you see fit.

Not tested, but pseudo wise something:

const { getAccessTokenSilently } = useCustomAuth0();

Where useCustomAuth0 would look something like this:

function useCustomAuth0() {
  const auth0 = useAuth0();
  const myState = useMyState();

  return {
    ...auth0,
    getAccessTokenSilently: () => auth0.getAccessTokenSilently({ authorizationParams: { foo: myState.foo } })
  }
}

That should allow you to ensure the correct parameters are always passed to our SDK.