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)
Prithviraj Sukale
don’t use it.
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).
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.
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 ?
Hester
Maybe in cookies
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.
Bujupah
Encode the request remote address to the JWT, so you may be able to limit the access
Tallam Hemanth
Then what to use
Rajendra Varma
Nice article!
Developers can also glance JWT brief info, FAQs and can debug at https://jwt.tool-kit.dev/
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.
Ali Hashim
I really like this idea!
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.
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.
Adithya Shasa Sai
if client has dynamic ip address allocation then token will invalidated even though he is a real client.
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 ?