In local storage of my React app, I notice that the okta-token-storage contains both idToken and accessToken.
I’ve set my Access token lifetime is in polices is 1 hour. After this time has passed, the token vanishes from local storage. I’d like to ask whats therefore the point of this token? Particularly as the idToken contains more info, like user details.
Also to confirm, its idToken that gets auto refreshed if I do authClient.tokenManager.get("idToken"); - correct?
And out of interest, once it vanishes, can I get it back?
It vanishes if you log out, or if you reload the page (and the route you’re on is a <SecureRoute …> route)and the libraries call to refresh the tokens fails and redirects to login. The access token lifetime shouldn’t even matter. It’s the refresh token lifetime that matters. This is usually set much longer than the access token timeout in the Okta dev dashboard somewhere.
You use the access token to send as a bearer against your backend to access protected APIs. Your backend would use this access token to allow/disallow (using some Okta validator library) the api call to proceed. The id token will contain some user information. To retrieve more information on a user, you would need to make a sperate api call to Okta.
Basically the thing I don’t understand is it says I should use accessToken to send across to with my API requests - however if this vanishes, how do I recreate it? And if it does vanish, why is it not a good idea to use idToken which always appears there?
p.s. I was just retesting this and this time the accessToken doesn’t seem to vanish, it just hangs around, when it expires a new one is created.
The only reason it vanishes are due to the scenarios I’ve already explained. Please explain to me your exact scenario where you found the accessToken gone from localStorage. Maybe I’m missing something here in understanding your situation.
Also, aren’t you using some Okta library for your backend to validate the token? In this case, you need to provide the accessToken during your backend check.
Are you using the default redirected Okta sign in page, or the Okta customizable widget component in React? If you’re using the default redirected Okta sign in page, this page runs off the same session as Okta, so if you sign out of the Okta developer dashboard, then try to access your app, you’ll be logged out.
The access token and ID token are separate because they are used for different purposes.
The access token is what determines whether or not the client has access to a particular API when it requests access.
The ID token contains information about the user such as first name, last name, email address.
You wouldn’t use the ID token for access because it doesn’t contain any information about whether or not the user should have access. If your app is evaluating access based off of information in the ID token such as email address, then you should probably be using a different authentication mechanism such as SAML.
Similarly you can’t use an access token for ID information as it’s only purpose is to validate that a user has access to a particular resource. If you need information about the user to, for example, write a log of who accessed what or send an email confirmation to the user, you get that information from the ID token.
I agree with the OP here. I actually don’t understand why Okta by default would store any access token in any local or session storage. This storage isn’t secure so I would have preferred Okta let me decide what to do with the access token and not store sensitive information in plain sight. Any hacker can easily get the token.