Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Where to store JWT

Tags:

javascript

jwt

I barely started reading about JWT and I beliave I understand what a JWT token is. I am also fairly familiar with SESSIONS. And I believe I understand the pros of each as well as their cons. However, there are a couple of parts where I am confused.

When requesting a protected resource, you need to send the jwt on each request, as opposed to having a session stored on the server. But:

1) how do you store your JWT token and where. From what I read I understood that you send your request to authenticate to the server and the server sends you a JWT token if you are successfully authenticated. Then what do you do?, do you store the JWT in a cookie as I have read in some sites? If so, how do you do it (using php, using javascript). And how do you read it.

2) When using session, more or less you just check that there is a session to check the user is logged in. How do you accomplish this when using JWT.

Also I have seen this on some pages:

RewriteCond %{HTTP:Authorization} ^(.*)
RewriteRule .* - [e=HTTP_AUTHORIZATION:%1]

How is this related to this (if related at all)

like image 777
Gacci Avatar asked Nov 07 '17 06:11

Gacci


People also ask

Where should I store my JWT token?

To keep them secure, you should always store JWTs inside an httpOnly cookie. This is a special kind of cookie that's only sent in HTTP requests to the server. It's never accessible (both for reading or writing) from JavaScript running in the browser.

Is it safe to store JWT in local storage?

A JWT needs to be stored in a safe place inside the user's browser. Any way,you shouldn't store a JWT in local storage (or session storage). If you store it in a LocalStorage/SessionStorage then it can be easily grabbed by an XSS attack.

Should I store JWT in local storage or cookie?

Storing Your JWT/Auth Token Hence, it's always best to store JWTs in http only cookies. Http only cookies are special cookies that cannot be accessed by client side JavaScript. This way they're secure against XSS attacks.

Where is the best place to store a token?

Browser in-memory scenarios Auth0 recommends storing tokens in browser memory as the most secure option. Using Web Workers to handle the transmission and storage of tokens is the best way to protect the tokens, as Web Workers run in a separate global scope than the rest of the application.

Where should JWT tokens be stored?

A common practice for beginners is to store the JWT tokens in local store. The reason for this is because it allows for a universal place to grab the token for when you need it and its pretty simple to do. However it is not a very good idea and leaves you open to cross-site scripting (XSS) attacks.

Why don’t we store JWT in local storage?

Why don’t we store JWT in local storage A common practice for beginners is to store the JWT tokens in local store. The reason for this is because it allows for a universal place to grab the token for when you need it and its pretty simple to do. However it is not a very good idea and leaves you open to cross-site scripting (XSS) attacks.

Where to store JWT and XSRF?

Whether you store your JWT in the localStorageor you store your XSRF-token in not HttpOnly cookie, both can be grabbed easily by XSS. Even your JWT in an HttpOnly cookie can be grabbed by an advanced XSS attack like XST method.

Where do you store JWT cookies?

In web browser, you can store JWT in local/session storageor in cookie. Both have vulnerabilities. You can choose the one you prefer, but you should take the security as a whole to be secured and processes should be well designed. If you prevent only against XSRF and XSS it will not help you.


1 Answers

  1. From client side, the good practice is store JWT in cookie, with mode http_only=true, is_secure (so that only send through https), so that JWT is not accessible by javascript. Then, we don't worry about XSS attach.

  2. We dont need to store the session on server side. A JWT contains two parts, the payload data, and signature, signed by a secret key stored on server side, and only the server could know. When we receive the token from client, we check the payload data is valid or not (user information, who assigned that token, assigned that token to whom, which roles granted with the token, expired time), and we check the signature to make sure that the token is assigned by the server, not faked. Then the user will be authenticated.

It's like a passport the government give to its citizen, the data (payload) is readable for everybody, but the signature can only created by the government, and it can verify against that.

like image 144
Daniel Tran Avatar answered Oct 26 '22 10:10

Daniel Tran