React app, getting id_token and token at same time

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 https://auth0.com/blog/react-tutorial-building-and-securing-your-first-app/) 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)

How could I go about doing this?

Hi @lawrence_cribadvisor,

Welcome to the Community!

There are a few things here that need clarifying.

  • 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.

  • What is your desired token lifetime?

Let me know,
Dan

Hi @dan.woda,

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

Thanks
Lawrence

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.

Does that solve it?

Thanks a lot for your help @dan.woda,

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?

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.