We need to store the JWT on the client computer. If we store it in a LocalStorage/SessionStorage then it can be easily grabbed by an XSS attack. If we store it in cookies then a hacker can use it (without reading it) in a CSRF attack and impersonate the user and contact our API and send requests to do actions or get information on behalf of a user.
But there are several ways to secure the JWT in cookies to not to be stolen easily (but there are still some advanced techniques to steal them). But if you wanna rely on LocalStorage/SessionStorage, then it can be accessed by a simple XSS attack.
So to solve the CSRF problem, I use Double Submit Cookies in my application.
Double Submit Cookies Method
Store JWT in a HttpOnly cookie and used it in secure mode to transfer over HTTPS.
Most of CSRF attacks have a different origin or referrer header with your original host in their requests. So check if you have any of them in the header, are they coming from your domain or not! If not reject them. If both origin and referrer are not available in the request then no worries. You can rely on the result of X-XSRF-TOKEN header validation results which I explain in the next step.
While the browser will automatically supply your cookies for the domain of the request, there is one useful limitation: the JavaScript code that is running on a website cannot read the cookies of other websites. We can leverage this to create our CSRF solution. To prevent CSRF attacks, we must create an extra Javascript readable cookie which is called: XSRF-TOKEN. This cookie must be created when the user is logged in and should contain a random, un-guessable string. We also save this number in the JWT itself as a private claim. Every time the JavaScript application wants to make a request, it will need to read this token and send it along in a custom HTTP header. Because these operations (reading the cookie, setting the header) can only be done on the same domain of the JavaScript application, we can know that this is being done by a real user who is using our JavaScript application.
Angular JS makes your life easy
Fortunately, I am using Angular JS in our platform and Angular packages the CSRF token approach, making it simpler for us to implement. For every request that our Angular application makes of the server, the Angular $http service will do these things automatically:
- Look for a cookie named XSRF-TOKEN on the current domain.
- If that cookie is found, it reads the value and adds it to the request as the X-XSRF-TOKEN header.
Thus the client-side implementation is handled for you, automatically! We just need to set a cookie named XSRF-TOKEN on the current domain in server side and when our API got any call from the client, it must check the X-XSRF-TOKEN header and compare it with the XSRF-TOKEN in the JWT. If they match, then the user is real. Otherwise, it's a forged request and you can ignore it. This method is inspired by the "Double Submit Cookie" method.
Caution
In reality, you are still susceptible to XSS, it's just that attacker can't steal you JWT token for later use, but he can still make requests on your users' behalf using XSS.
Whether you store your JWT in the localStorage or 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.
So in addition to the Double Submit Cookies method, you must always follow best practices against XSS including escaping contents. This means removing any executable code that would cause the browser to do something you don’t want it to. Typically this means removing // <![CDATA[ tags and HTML attributes that cause JavaScript to be evaluated.
Read more here:
Best Answer
Short answer
JWTs are a convenient way to encode and verify claims.
A Bearer token is just string, potentially arbitrary, that is used for authorization.
Context (story time)
A few years ago, before the JWT revolution, a
<token>was just a string with no intrinsic meaning, e.g. 2pWS6RQmdZpE0TQ93X. That token was then looked-up in a database, which held the claims for that token. The downside of this approach is that DB access (or a cache) is required everytime the token is used.JWTs encode and verify (via signing) their own claims. This allows folks to issue short-lived JWTs that are stateless (read: self-contained, don't depend on anybody else). They do not need to hit the DB. This reduces DB load and simplifies application architecture because only the service that issues the JWTs needs to worry about hitting the DB/persistence layer (the
refresh_tokenyou've probably come across).