My problem boils down to the use of Okta's access tokens to secure api endpoint.

I followed this okta guide to set up a react single-page application with their wiget.

When I log into the site I get a access token to use with my api.

I tried to access my api with the access token following this guide

On the api side Okta recommended to verify the access token. When I use their OktaJwtVerifier to verify the token I get faced with a question. How does this verifier know that I gave them the token from a authorized state and not from someone hijacking the token?

The verifier supposedly asserts that

  • Signature is valid
  • Access token is not expired
  • The aud claim matches any expected aud claim passed to verifyAccessToken().
  • The iss claim matches the issuer the verifier is constructed with.
  • Any custom claim assertions that you add are confirmed

But the validator does not know where the token came from.

I noticed that the access token gets saved into localStorage.

Does this not open up for a impersination attack on the access token? Suppose someone got access to the localStorage and used the access token on my api without authenticating. I tested if this would work and it did.

How can I prevent someone from stealing and using my access token without authenticating ???

  • 2
    How would someone get access? If they already have local access, it's game over. Jul 25, 2020 at 23:10
  • 2
    You can't. No one can. HTTP is fundamentally incapable of solving this problem Jul 26, 2020 at 2:17

2 Answers 2


As @multithr3at3d commented, if the attacker already has local access its game over. There isn't much you can do to protect against session hijacking if an attacker has compromised your user's device. You could try to check the IP of the client when it makes a request to ensure that it is the same IP from which the session was initiated. This isn't a good idea for several reasons. It wouldn't prevent an attacker that shares the same IP (i.e. connected on the same WiFi). It wouldn't really stop an attacker who has installed malware on the victim's computer, since they could proxy their requests through the victim's computer. And it would be a major inconvenience if someone's IP changes during a valid session.

The best you could do is expire sessions after some period of inactivity combined with requiring reauthentication before performing critical actions to reduce the window of attack for attackers who somehow stole the access token. Again, this wouldn't help much in the case of an attacker with local access, since they could simply steal the token again when the user logs back in, or better yet, keylog their login credentials.


There is actually one small thing you might check to see, if the request comes from the authenticated user, that has little probability to backfire (unlike the IP check) and a bit of chance to actually prevent an attack. Look on the User-Agent header. It is not expected that within the user session the value of the header changes. If it does, then it might be due to attacker activity.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .