# What Happens If Your Jwt Is Stolen? **URL:** \ **Category:** Developer Blog Comments\ **Created:** [June 20, 2018, 4:48pm UTC](https://devforum.okta.com/t/what-happens-if-your-jwt-is-stolen/16885 "2018-06-20T16:48:27Z")\ **Posts on this page:** 16\ **Page:** 2
**Author:** ![oktadev-blog](https://sea1.discourse-cdn.com/oktadev/user_avatar/devforum.okta.com/oktadev-blog/32/3422_2.png) [@oktadev-blog](https://devforum.okta.com/u/oktadev-blog)\ **Post date:** [February 4, 2020, 5:16pm UTC](https://devforum.okta.com/t/what-happens-if-your-jwt-is-stolen/16885/21 "2020-02-04T17:16:26Z")
**Mykola Yiado** That’s wrong. You can have a cookie that is not accessible on the client and being sent only with requests to a server (httpOnly cookie) ---
**Author:** ![oktadev-blog](https://sea1.discourse-cdn.com/oktadev/user_avatar/devforum.okta.com/oktadev-blog/32/3422_2.png) [@oktadev-blog](https://devforum.okta.com/u/oktadev-blog)\ **Post date:** [March 10, 2020, 12:25am UTC](https://devforum.okta.com/t/what-happens-if-your-jwt-is-stolen/16885/22 "2020-03-10T00:25:51Z")
**Prithviraj Sukale** don’t use it. ---
**Author:** ![oktadev-blog](https://sea1.discourse-cdn.com/oktadev/user_avatar/devforum.okta.com/oktadev-blog/32/3422_2.png) [@oktadev-blog](https://devforum.okta.com/u/oktadev-blog)\ **Post date:** [May 13, 2020, 11:51am UTC](https://devforum.okta.com/t/what-happens-if-your-jwt-is-stolen/16885/23 "2020-05-13T11:51:42Z")
**Torchbug** You are both right. There is no “server-side cookies”, but there are cookies that can only be sent to a server (`HttpOnly` flag). ---
**Author:** ![oktadev-blog](https://sea1.discourse-cdn.com/oktadev/user_avatar/devforum.okta.com/oktadev-blog/32/3422_2.png) [@oktadev-blog](https://devforum.okta.com/u/oktadev-blog)\ **Post date:** [December 31, 2020, 2:50pm UTC](https://devforum.okta.com/t/what-happens-if-your-jwt-is-stolen/16885/24 "2020-12-31T14:50:10Z")
**IWBAB** Can’t we add “ip address” of user in payload of “jwt” and when requests arrive, we check if the “ip address” in payload is same as from where the request arrived?? It reduces the threat as the attacker must be connected to the same wifi network. ---
**Author:** ![oktadev-blog](https://sea1.discourse-cdn.com/oktadev/user_avatar/devforum.okta.com/oktadev-blog/32/3422_2.png) [@oktadev-blog](https://devforum.okta.com/u/oktadev-blog)\ **Post date:** [January 7, 2021, 8:52am UTC](https://devforum.okta.com/t/what-happens-if-your-jwt-is-stolen/16885/25 "2021-01-07T08:52:03Z")
**Geoffrey GESLIN** I still don’t get why long lived refresh tokens are a better solution. If a JWT token can be stolen, why won’t both access token _and_ refresh token be stolen ? Are refresh tokens supposed to be stored more securely ? How ? ---
**Author:** ![oktadev-blog](https://sea1.discourse-cdn.com/oktadev/user_avatar/devforum.okta.com/oktadev-blog/32/3422_2.png) [@oktadev-blog](https://devforum.okta.com/u/oktadev-blog)\ **Post date:** [January 16, 2021, 4:28pm UTC](https://devforum.okta.com/t/what-happens-if-your-jwt-is-stolen/16885/26 "2021-01-16T16:28:30Z")
**Hester** Maybe in cookies ---
**Author:** ![oktadev-blog](https://sea1.discourse-cdn.com/oktadev/user_avatar/devforum.okta.com/oktadev-blog/32/3422_2.png) [@oktadev-blog](https://devforum.okta.com/u/oktadev-blog)\ **Post date:** [January 22, 2021, 11:58am UTC](https://devforum.okta.com/t/what-happens-if-your-jwt-is-stolen/16885/27 "2021-01-22T11:58:44Z")
**Peter Labos** On some sites I have seen different way to handle possibility of stealing JWT. For any sensitive operation they force re-authentication on user if token is older than 5-15 minutes. Like when user is trying to change personal details like address, bank card details or when trying to pay for what it is in the cart. ---
**Author:** ![oktadev-blog](https://sea1.discourse-cdn.com/oktadev/user_avatar/devforum.okta.com/oktadev-blog/32/3422_2.png) [@oktadev-blog](https://devforum.okta.com/u/oktadev-blog)\ **Post date:** [February 4, 2021, 10:01am UTC](https://devforum.okta.com/t/what-happens-if-your-jwt-is-stolen/16885/28 "2021-02-04T10:01:59Z")
**Bujupah** Encode the request remote address to the JWT, so you may be able to limit the access ---
**Author:** ![oktadev-blog](https://sea1.discourse-cdn.com/oktadev/user_avatar/devforum.okta.com/oktadev-blog/32/3422_2.png) [@oktadev-blog](https://devforum.okta.com/u/oktadev-blog)\ **Post date:** [February 25, 2021, 11:12am UTC](https://devforum.okta.com/t/what-happens-if-your-jwt-is-stolen/16885/29 "2021-02-25T11:12:53Z")
**Tallam Hemanth** Then what to use ---
**Author:** ![oktadev-blog](https://sea1.discourse-cdn.com/oktadev/user_avatar/devforum.okta.com/oktadev-blog/32/3422_2.png) [@oktadev-blog](https://devforum.okta.com/u/oktadev-blog)\ **Post date:** [April 19, 2021, 12:10pm UTC](https://devforum.okta.com/t/what-happens-if-your-jwt-is-stolen/16885/30 "2021-04-19T12:10:52Z")
**Rajendra Varma** Nice article! Developers can also glance JWT brief info, FAQs and can debug at [https://jwt.tool-kit.dev/](https://jwt.tool-kit.dev/ "https://jwt.tool-kit.dev/") ---
**Author:** ![oktadev-blog](https://sea1.discourse-cdn.com/oktadev/user_avatar/devforum.okta.com/oktadev-blog/32/3422_2.png) [@oktadev-blog](https://devforum.okta.com/u/oktadev-blog)\ **Post date:** [May 31, 2021, 8:00am UTC](https://devforum.okta.com/t/what-happens-if-your-jwt-is-stolen/16885/31 "2021-05-31T08:00:12Z")
**Tafadzwa Chingaira** The other reason he did that was to avoid outputting ‘undefined’. This is JS… The **console** line can run before the token variable has been instantiated. ---
**Author:** ![oktadev-blog](https://sea1.discourse-cdn.com/oktadev/user_avatar/devforum.okta.com/oktadev-blog/32/3422_2.png) [@oktadev-blog](https://devforum.okta.com/u/oktadev-blog)\ **Post date:** [July 22, 2021, 11:55pm UTC](https://devforum.okta.com/t/what-happens-if-your-jwt-is-stolen/16885/32 "2021-07-22T23:55:26Z")
**Ali Hashim** I really like this idea! ---
**Author:** ![oktadev-blog](https://sea1.discourse-cdn.com/oktadev/user_avatar/devforum.okta.com/oktadev-blog/32/3422_2.png) [@oktadev-blog](https://devforum.okta.com/u/oktadev-blog)\ **Post date:** [July 23, 2021, 12:03pm UTC](https://devforum.okta.com/t/what-happens-if-your-jwt-is-stolen/16885/33 "2021-07-23T12:03:44Z")
**Ali Hashim** that’s a really interesting question. here’s my take on it: access\_tokens can be stolen because the attack surface is greater. think of a typical website with many SPAs developed by different developers all using the same access\_token. some SPAs allow third party scripts and others do not. If there was a MITM attack, it could snoop on the traffic to get the access\_token. Similarly, the access\_token may be stored in local storage making it easier for js to have access to it. but what about refresh\_token I hear you say. the attack surface here is then down to implementation. to secure refresh token, you could 1) set this value in a server side cookie; 2) when the access token has expired, redirect user to the auth app which will do the token exchange and get a new access token and then the app should redirect you back. crucially, the auth app will have higher security than other parts of the system like no 3rd party js allowed, captcha on the page in case you’re unrecognised. the auth app should make a call to BE server to get access token and the refresh token is sent automatically. both these should mitigate against MITM attack. ---
**Author:** ![oktadev-blog](https://sea1.discourse-cdn.com/oktadev/user_avatar/devforum.okta.com/oktadev-blog/32/3422_2.png) [@oktadev-blog](https://devforum.okta.com/u/oktadev-blog)\ **Post date:** [July 27, 2021, 7:04pm UTC](https://devforum.okta.com/t/what-happens-if-your-jwt-is-stolen/16885/34 "2021-07-27T19:04:30Z")
**IWBAB** Add issueDate in payload while creating jwt and in db maintain a datetime field, let it be lastRequestForLogoutFromAllDeivices. Now whenever user requests for logout from all devices update **lastRequestForLogoutFromAllDeivices**. On subsequent requests check if issueDate is always greater than **lastRequestForLogoutFromAllDeivices** else invalidate that jwt and redirect to login. ---
**Author:** ![oktadev-blog](https://sea1.discourse-cdn.com/oktadev/user_avatar/devforum.okta.com/oktadev-blog/32/3422_2.png) [@oktadev-blog](https://devforum.okta.com/u/oktadev-blog)\ **Post date:** [August 22, 2021, 3:09am UTC](https://devforum.okta.com/t/what-happens-if-your-jwt-is-stolen/16885/35 "2021-08-22T03:09:12Z")
**Adithya Shasa Sai** if client has dynamic ip address allocation then token will invalidated even though he is a real client. ---
**Author:** ![spatial](https://avatars.discourse-cdn.com/v4/letter/s/7993a0/32.png) [@spatial](https://devforum.okta.com/u/spatial)\ **Post date:** [December 12, 2021, 4:45am UTC](https://devforum.okta.com/t/what-happens-if-your-jwt-is-stolen/16885/36 "2021-12-12T04:45:10Z")
Logout and blacklisting of the token can be done for APIs based on audiences, scopes and claims. This is what I understand. So if I logout of the main API and token can still be used to access the remaining API. This is our requirement. But I am somewhat confounded by the possibilities. What is an audience ? Can roles be in scopes and claims ? Looking for a basic design for audiences, scopes and claims. Any public material ? [Previous page](https://devforum.okta.com/t/what-happens-if-your-jwt-is-stolen/16885.md?page=1)