I'm using The Microsoft.Owin.Security.Jwt provider for auth in a HTML5/ASP .NET application - to make it more secure, is there anyway to instruct the API to write/read the token to a HttpOnly and Secure (HTTPS) only cookie? At the moment, it's returning the token via the HTTP response body and expecting the token to be sent on the 'Authorization' header.
Thanks.
I do not think there is a free way to do this, you will have to do this yourself.
JWT and Cookies are very different concepts and they should not be mixed.
Related
I wanted to save a bearer token to authenticate APIs on the client. I read that http-only cookies and localstorage have different downsides, and felt that using both at the same time would improve security.
Would it be wise to save half of the token in an http-only cookie and half in localstorage, or should I only use one of them?
With SameSite being set to Lax or Strict, the cookie will get the CSRF protection that was the primary weakness that caused a move from cookies to bearer tokens. A cookie that is set to Secure, HttpOnly and SameSite=Lax/Strict will only be sent on HTTPS, not be available to script and have a decent protection against CSRF.
Bearer tokens saved in local storage will be accessible to script, and can thus be stolen in XSS attacks, just as with cookies lacking the HttpOnly flag.
If you store half in local storage and half as a cookie you are probably going to combine the parts before using it in a request header. In this case you can't set HttpOnly flag on the cookie, and you will lose the benefits that cookie storage can provide. Consequently it doesn't make sense to split the bearer token.
If you are in this situation because you use the implicit code flow of OAuth 2.0, please be adviced that this flow is now deprecated and you should use Authorization code with PKCE flow instead, and your authentication token should be stored in a cookie hardened as described above.
I usually use JWT tokens but I know this is not so secure because when you store the token on LocalStorage you are susceptible to attacks.
What is the best and most secure way for a good session and auth management?
The generally accepted standard is storing JWT inside an httpOnly cookie. So the JWT/Cookie will only be sent to the HTTP server and would not be accessible for reading or writing on the client side. To make it more secure you can set SameSite=strict to eliminate cross site request forgery (CSRF) unless you require the JWT to fetch information from a different domain.
There probably are more secure ways to do this?, but I believe this would be more than enough for an average website.
Is it secure to store JWT in localStorage? The thing is that I tried storing JWT in cookies in NodeJS with httpOnly set to true. But the thing is that I cannot access the cookie in reactJS using universal cookies. Is it true that nodeJS generated cookies with httpOnly set to true is not possible to access on the ReactJS client side?
So, is it secure to store JWT in localStorage? Or it is totally secure because of the token secrets?
Many thanks in advance and greatly appreciated.
Its better not to.
The JWT Should stay in cookies with httpOnly.
I dont think there is any reason for you to use the JWT at the front, all you have to do is to use withCardentials and it will send it automatically every request.
If you have data you need that stored inside the JWT, you create a route that open it and send it back to you(with validation of course).
P.S: the reason that you dont want it to be at the localStorage is that you want it to be safe, that no scripts will be allowed to get those tokens.
I am building a Node web app using JWT for user auth.
My server sends JWT in HTTP-Only cookie via 'Set-Cookie' when user submits correct id and password, but I am stuck on how to access that JWT stored within the cookie so that I can include it in the Authorization header when making authorized API requests.
How can I access the HTTP-Only cookie from client-side to include it when sending API request to server?
Or, would it be safe to just not use the cookie at all by having the server send the JWT in response body? So that I use the JWT by putting it in a client-side variable? That way, I believe the variable is only alive until the user closes the browser.
I have looked for many resources, but was not able to find clear answer to this issue that I am stuck with.
While there are numerous ways to solve this problem, I will suggest the method where the client sends the JWT twice on each request: in an HttpOnly cookie, and also an an Authentication: header.
Let's examine what security issue each is solving:
HttpOnly Cookie
From the Mozilla documentation:
To help mitigate cross-site scripting (XSS) attacks, HttpOnly cookies are inaccessible to JavaScript's Document.cookie API; they are only sent to the server.
This is to mitigate cross-site scripting risk; imagine your website has an XSS vuln -- for example I can put <script>some_code{..}</script> into a comment, and any user who views my comment will have my code running in their browser. Yes, the attacker's code is running inside the victim's logged-in browser, but because of the HttpOnly flag, it can't extract the session cookie and send it to the attacker.
Authentication header
The problem with cookie authentication is that the browser will automatically attach them to any request to the domain that the cookie belongs to, this allows cross-site request forgery attacks. To prevent this, the usual method is to send the session token (in your case a JWT) to the client in a method other than a cookie, ie in a different header, or maybe in a hidden HTML field.
If the client is able to echo the JWT token back to you on their next request, that means they were able to read the previous response, and are not an attacker doing a blind injection CSRF attack.
Overall Suggestion
Combine the two!
The two methods serve different purposes: HttpOnly cookies protect against XSS attacks while Authentication headers protect against CSRF attacks.
There are many ways to combine them, but they all boil down to putting the JWT in some sort of authentication header, and putting a sessionID in the cookie, and having the server check that these belong to the same session. Important: remember that an attacker who achieves XSS on your site will be able to read the JWT, so for the cookie to be doing its job, the cookie should be a separate value that is not contained in the JWT. (ie if the attacker can figure out the right cookie value by looking at the JWT, then the cookie is not providing any security).
We used to set httpOnly to be false of the xsrf token set by the server so that our javascript can read it and attached it to the request header. However, our security team prohibits any cookie to be httpOnly false.
Our backend only returns json data and does not render any client-side html. Is there an alternative way to include the xsrf token in our request header?
Thanks.
The csrf token cookie is an obvious exception from the httpOnly requirement. Your security department should allow this, as double posting is a standard, owasp-supported protection against csrf. There is no way to do this with a httpOnly cookie, that's the point.
If they insist (which doesn't make any sense), you will have to choose a different method, for example synchronizer tokens.