Cookies
- Has only 4kb of holding capacity
- Supported in both HTML4 and HTML5
- Accessible from any window inside the browser
- Expiration date can be manually set
- Can be stored on both browser and server
- Can be sent with API Requests
>document.cookie = "username=John Doe; expires=Thu, 18 Dec 2013 12:00:00 UTC; path=/";
<'username=John Doe; expires=Thu, 18 Dec 2013 12:00:00 UTC; path=/
Local storage
- Has 10mb of holding capacity
- Supported in HTMLS only
- Accessible from any window inside the browser
- No expiration date
- Can be stored on browser only
- Cannot be sent with API Requests
>LocalStorage.setItem("name ', "san')
<undefined
>localStorage.getItem('name')
<"san
>LocalStorage.removeltem( "name )
<undefined
>LocalStorage.getItem('name')
<null
Session storage
- Has 5mb of holding capacity
- Supported in HTML5 only
- Accessible only in same tab inside the browser
- Expires on tab close
- Can be stored on browser only
- Cannot be sent with API Requests
> sessionStorage.setItem('name, rock)
< undefined
> sessionstorage.getItem('name)
<rock
> sessionstorage.removeltem('name)
< undefined
> sessionStorage.getItem('name')
What do you think is the best and more secure to use ?
Share your ideas and feedbacks in the commetns section, I'll be waiting for your great insights !!
Top comments (3)
None of them are secure, so don't go storing unencrypted secrets there. I've used both cookies and local storage in the past, but this is the first I've heard about session storage 😀.
It seems like a matter of scope and convenience. Cookies are convenient, being sent automatically provided that the domains match up. In authentication scenarios, cookies and bearer tokens can be used interchangeably, and the cookie might save you some coding. However, in cases where the domain doesn't line up, you'll need to use bearer tokens instead, which can be saved to local storage along with the refresh token.
The only difference, then, is whether you want your client app data to be stored beyond the browser session or not. This seems to be something you could control with a "Remember"-type option. Overall, all three have their uses. And cookies are not exclusive of the other two. But none of them are inherently secure, so ensure that you store only encrypted data in all these locations.
so what do you suggest can be the most secure option to authenticate a user using jwt tokens?
I guess it would help to look at what you are actually trying to prevent. In my case, I'm interested in ensuring that an application user who accesses the application on a public terminal is not exposing their credentials to the next terminal user. The terminal user may: have access to your browser session if you forgot to close the browser; have access to your cookies; have access to your local storage. As you can see, all of these locations are potentially readable by another user of the terminal. A JWT is transferrable (though it does expire), so the next terminal user has the lifetime of the JWT to use it maliciously.
The description above is what I meant when I said "insecure". You cannot prevent another user from reading these storage locations. Therefore, you need to encrypt any sensitive data that goes in there, including your JWT. At some point though, you can only obfuscate it, because you'll have to put the encryption key somewhere on the client side too.
One method I've used to guard against the transferabiliity of JWTs is to include an HMAC signature and nonce with each request. That way, each request can only be used once and the JWT is not immediately useful to someone who intercepts it. This gets into more advanced cryptography though, and is maybe more than you need to worry about for most applications.