auth0-spa-js: Trigger a refresh for the getUser method
Describe the problem you’d like to have solved
Note My app is an Angular8 app, that uses the
AuthService
provided in the Auth0 Angular Tutorial.
After users first logged into my app, they must complete their profile with some information. On Auth0, upon signup, I initialize every account with an app_metadata
named complete
with a value of false
.
When a user complete their profile, the backend that recevies this completed profile sends a request to the Auth0 Management API to change this app_metadata.complete
value from false
to true
.
But the frond end is not aware of this update, since it’s happening behind it’s back.
I tried making a method that calls getTokenSilently
and ignoring the cache, in order to get the latest version of my user’s tokens, then calling the getUser
method to retrieve the user’s profile from the tokens.
Except that the profile is still the old one, with the complete: false
value.
Describe the ideal solution
I need a way to somehow trigger a refresh of the currently logged in user info.
Something along the line of getTokenSilently({ ignoreCache: true})
, but for the decoded user profile (e.g. getUser({ ignoreCache: true })
or getUser({ forceRefresh: true ])
).
Alternatives and current work-arounds
The workaround I have now, is when the backend finishes updating the user account on Auth0, the front end calls the login
method of the AuthService
. That restart a complete login process, but since my user already logged in before, it behave like an SSO login, and the app is simply reloaded.
That works… but I’d like to avoid this full reload for a more streamlined user experience.
I’d like to add that I don’t dismiss the possibility this is already achievable and I just don’t saw how 😅
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Reactions: 4
- Comments: 24 (11 by maintainers)
@patricknee I’m trying to replicate your issue, and I have uncovered a bug - which might be related - relating to specifying options to
getTokenSilently
. Because you’ve specified an options object, it causes the SDK to not send an audience value or scopes, meaning you don’t get an access token in JWT format returned to you.To rule it out in case this is affecting you, could you please manually specify the
audience
value in the call togetTokenSilently
where you ignore the cache? Something like this:This will be fixed anyway but would be good to try it out in your case.
This would be super useful for me too.
Refreshing the access token using
getTokenSilently({ignoreCache:true})
and thengetUser()
is working for me, but would certainly prefer to not have to refresh my accessToken, am using react hooks and my data retrieval on the page is re-triggered if the access token changes with auseMemo
, would prefer not to have to reload my data just because the users profile has changedOhhh, I see it. Sorry, should have caught up on the entire thread.
Yes,
getAccessTokenSilently({ignoreCache: true})
does work, it does indeed pull the fresh id token and properly refreshes theuser$
observable.A bit counter-intuitive though 😃
Thanks!
@prostakov using
getTokenSilently({ cacheMode: 'off'})
should work. There is no such thing as getting the user from Auth0 using our SDK, instead we get a set of tokens and use the id token to extract the information and build a user that you can retrieve from our SDK. If you want to refresh the user, you should refresh the token and it should reflect in the updated user.Are you experiencing issues when trying to use
getTokenSilently
like that?@stevehobbsdev Sorry for my misunderstanding. It actually worked when I used my own Google developer credentials.
@Tazaf Yes you’re right. Right now, if you want to refresh the ID token you would have to call
getTokenSilently({ ignoreCache: true })
first in order to refresh the cache.getIdTokenClaims()
just returns what it already knows about the token and does not refresh it, as you’ve observed.Not saying that’s entirely ideal or obvious, but what we’re discussing here is a potential new use-case and we could make this easier for you in the future, depending on the outcome of this issue.
What I’m interested in is if you can call
getTokenSilently
first, ignoring the cache but without specifying an audience value and observe the results. Then try specifiying an audience in thegetTokenSilently
call and see what happens.Hi @stevehobbsdev
Thanks for the heads up. I’ve been caught up with other tasks lately. I’m trying this thread’s suggestions right now. I’ll come back when I have some results.