I’m currently retrieving and using id_token with auth0js WebAuth and parseHash, using the responseType ‘id_token’, but I’m looking for a way to get both the idToken and authToken in the same result.
I was able to do this by adding the scopes I needed to WebAuth and by changing responseType to ‘id_token token’ and setting the audience to my Management API URL, so I now have authResult containing ‘idToken’ (the same method used in this post The Complete Guide to React User Authentication with Auth0) and after the changes, also containing ‘accessToken’.
I noticed however that expiresIn is 7200secs (2hrs) while the authResult.idTokenPayload.exp is 10hrs, and my code checks if the user is authenticated by checking the current date against the idToken expiry which is more than the management API expiry, where I really want both to expire at the same time (I want to be able to use both for different reasons in the app)
You should be able to get an access token and an id token without having to declare an audience, although the access token will be opaque
Are you using the access token to make requests to the management API? Or did you set that as the audience arbitrarily to get a non-opaque token? The managment API and the authentication API are seperate entities.
Yes I’m using the audience so that I can use the management API from my app so that users can update their own user_metadata directly, and also using the authentication API to log in and manage roles through rules etc.
Is there any reason that I might not want to specify the audience in this case?
Ideally I would like to keep both tokens around at the same time because I am using both for different purposes as mentioned, without needing to worry about one expiring without knowing about it
This is all totally fine. Client side communication to the management API is fairly constrained and I wanted to make sure this wasn’t causing an unnecessary problem.
That makes sense. I think the conflict here is arising because tokens obtained in the client and destined for the management API are locked at a 7200s lifetime. You could change your id token lifetime to match if you like.
So the management API token is hard limited to 7200? So my only option is to limit the login to 7200 seconds before authenticating again/changing the id_token expiry to 7200?
I suppose another way that it could be done is by requesting an access token each time I want to update the user_metadata, but this would require redirecting the user (I couldn’t do it silently in the background,) am I correct in thinking?