I've been reading articles about JSON Web Token (which is completely new to me) and its safe mechanism to transmit information between parties in order to avoid server Sessions.
I'm building a web app from scratch using Java, Tomcat, Jersey framework for Web Services and JOSE4J for the JWT.
Many articles advice to use Cookies httpOnly instead of localStorage
I've already created a restful method like this with a cookie and the jwt
#GET
#Path("/authenticate")
#Produces(MediaType.APPLICATION_JSON)
public Response authenticate(
#HeaderParam("username") String username,
#HeaderParam("password") String password) throws JSONException,
IOException, JoseException {
Service service = Service.getInstance();
EmployeeProfile employeeProfile = service.authenticate(username, password);
// Temporarily httponly and secure as false to test
NewCookie cookie = new NewCookie("jwt", service.getToken(), null, null, null, 900, false, false);
return Response.status(200).cookie(cookie).entity(employeeProfile).build();
}
return Response.status(204).entity(null).build();
}
When I run my webapp in Chrome I can see that the cookie was saved correctly.
Now I can use this token to call further restful methods with no need to authenticate again, but what if Cookies are disabled? I cannot retrieve the cookie as I tested in incognito mode. In that case I can verify if cookies are enabled and warn the user to enable them in order to proceed with the login process.
To check cookies I do this:
$.cookie('test_cookie', 'cookie_value', { path: '/' });
if ($.cookie('test_cookie') !== 'cookie_value') {
//Cookies are disabled. Show a modal.
}
But this is very restrictive. So I wonder what would be my alternative to retrieve the jwt from server? I am not very sure about this, but should I change the controller to send the jwt as a part of the response in json and keep it in the localStorage even if this can expose my token to XSS attacks? However, using cookies can be also susceptible to CRSF attacks but not if I set httpOnly and secure properties to true, but in that case I won't be able to read the cookie with javascript. I am confused about this.
Thanks in advance.
You are right , You need to change your controller and send the JWT is part of the response as well as the cookies with flag httpOnly due securities, but the question is are decrypting JWT in client side and using some value from there. if "No", then no need to send JWT as part of the response.. if "Yes", better take out all that values from the token and send a separate json object in response header.
Related
This is my first attempt to dealing with server
Using React and express
Saving token to browser cookie from server
//After login request
res.cookie('token', token, {maxAge: 3600000} ).json({ user: userDoc, message: 'message!', status: 200 });
Question is here
How can I send token value from client along with each API request for further app process?
After research I found two options!.
Option A
//Collecting data from cookie
let token = Cookies.get('token');
axios.get("/api/, { headers: {"Authorization" : `Bearer ${token}`} });
Option B
Here is my confusion that I have read ,that browser send cookie along with each api automatically without manually adding in header
I have tested in server let { cookies } = req; and its working
Question
Which option is the correct way ?
If yes A or B - why? and why not?
Considering Option B is relying on server for dealing with cookies.
When dealing with sensitive data such as authorisation tokens, you must choose option B.
This is because the client side scripting should not get access to the sensitive data by any means.
To prevent client from accessing the cookie, use HttpOnly flag in your call to res.cookie.
HttpOnly cookies cannot be accessed by client side scripting. So it is pretty safe to use.
Even if data is not sensitive, you should go with option B. Since your browser is automatically sending the cookie payload, you don't have to deal with it manually.
In an angular application, I send an XHR login request to a stateless rest server with http auth header:
http
.get(`${site.url}/login`, {
headers: {
Authorization: `Basic ${btoa(`${username}:${password}`)}`,
},
withCredentials: true,
})
Anytime I request the same server then, I don't need to send the credentials again: they are saved automatically by the browser. This is nice, this way I don't have to save the credentials on the browser (the server is stateless, so there is no session nor token available).
However this introduces a security issue: when the user logouts (this is a simple boolean stored in the browser), his browser is still able to connect to the server: in case of XSS someone could connect again.
Is there any way, from Javascript, to clear these credentials? I saw some hacks (request the server with bad credentials...) but I am looking for a consistent & safe way.
Headers are immutable - they can't be changed. However you can use a technology called JWT (JSON Web Token).Here a link for JWT's website.
I have implemented JWT authentication using Node.js. When the user signs in, Node.js signs/creates a JWT and sends it back. Thereafter, it is stored in the localStorage. Now, this is probably where I am going wrong, but... to move forward, I make use of the express router, and within the router code (which is obviously at the node level) I want to be able to access the token (which is in localStorage) so that I can make a call to the API for further data. However, I just realised that localStorage is at the client-end and that node/express/router doesn't recognise localStorage. So I am stuck. Obviously, I am doing something fundamentally wrong... I should not need to access localStorage from the express router file. Perhaps, I should really be making the API calls not from the express router file, but from client side.
Any hints/directions?
localstorage is bad way to save token. you should save token in cookies and use then where you want.
EXAMPLE:
new Cookies(req,res).set('access_token',token,{
httpOnly: true,
secure: true // for your production environment
});
and then read:
var token = new Cookies(req,res).get('access_token');
You need to send the JWT that is stored on the client side every time you make an API request to the server side.
https://jwt.io/introduction/
Scroll down to the section How do JSON Web Tokens work? The JWT should be sent in the header of the API calls in the form:
Authorization: Bearer <token>
How you do this depends on how exactly you'll send the HTTP requests to the API, but it should be pretty simple in any respects. You can find out about how to add Headers to an angular $http request at this link:
https://docs.angularjs.org/api/ng/service/$http
Then it's up for each of your authenticated express routes to check the headers, pull the JWT out, ensure that it's valid, and then proceed with the request (or halt it if the JWT is invalid).
I have just learned about JWT for authentification. Storing the JWT token in localStorage/sessionStorage is exposed to XSS. Storing it in a cookie is vulnerable to CSRF. I have been researching this and I thought of this solution, but I'm not sure how secure is this and if I should be using it in production.
The soulution is to get the JWT token from server, store it in cookie. Generate a CSRF token (that will be stored in JWT) that will be sent with each HTML page, either in a hidden HTML field of as a global JS variable (). That CSRF token will be sent with every request using JS/AJAX. This way we can rule out CSRF first then verify the JWT token.
I'm not sure whether a new token should be sent with each loaded page, or a single token should be held per session. The 1st case would mean that only the last loaded page/form would be able to submit (which could be problematic if the user is having multiple tabs of other pages open).
Is this a secure solution that might be used in production ?
Also, what other solutions would be viable to reach the same goal ?
Here is my understanding of the issue.
JWT Token - stored in httponly/secure cookie - this ensures any Javascript does not have access to it
CSRF Token - stored by JS - on login, attach the claims as a header (including your CSRF value)
When the JS gets the header, it can store the claim in a cookie, localstorage, or session storage. Because no JS has access to the JWT token in the cookie, by attaching the CSRF with every request and making sure it matches what's in the JWT, you're ensuring that it's your JS sending the request and that it was your backend that issued the token.
A hidden field isn't a great solution because you'll have to add it to each request. Depending on what framework you're using, you should be able to load the CSRF token into whatever is responsible for sending the token as a header on each request when the page is refreshed. The benefit to having all the claims in local storage or a cookie is you can preserve the users front end state. Having the exp claim means you can tell when the user no longer has a valid token in the secure jwt token cookie and you can redirect to a login page.
sessionstorage - is specific to the tab only
localstorage - is specific to the domain across tabs
cookie - is specific to the domain across tabs
Add CSFR to AJAX request:
$.ajax({
type:"POST",
beforeSend: function (request)
{
request.setRequestHeader("CSRF-TOKEN", csrfToken);
},
url: "entities",
data: "json=" + escape(JSON.stringify(createRequestObject)),
processData: false,
success: function(msg) {
$("#results").append("The result =" + StringifyPretty(msg));
}
});
Even though you're not using Angular, this still applies. You should attach the token as a header with the JS and it's fine to get that value from a cookie.
From the Angular JS Documentation
When performing XHR requests, the $http service reads a token from a cookie (by default, XSRF-TOKEN) and sets it as an HTTP header (X-XSRF-TOKEN). Since only JavaScript that runs on your domain can read the cookie, your server can be assured that the XHR came from JavaScript running on your domain.
In my application,while registering the users i am saving username,password and jwt generated token with these fields in MONGO DB.When user tries to login with correct credentials then i will send the response with stored token.Then at client side(In my controller) i am using the localstorage to store the token so that i can send the same token for each and every request sent by the client.But I found some issues regarding this procedure:
I am generating same token for one user every time.So if any third person is able to get the token then he can access the restricted page.
Am i wasting space in db by storing the generated token in MONGODB
Can Anyone access the token stored in localstorage other than the user.
for each and every request in my single page application,I am again querying mongodb to get the token for that user and validating.Here,I am checking both client side and server side.
I am using jwt to generate tokens,Node,Express,Mongoose in my application
Am i following the good procedure.If not,can you please provide the solution for my approach or any new approach.
I have searched many sites for token based authorization and session based authorization,But nothing worked for me.
Note:I am beginner for Nodejs,AngularjS
You should store token in advanced key-value cache tool like: Redis
That would improve performance remarkably.
You will get token from database for 1st time then it should be stored in Redis. I used to set token as key and username as value. Next request , the token will be given from cache. with Redis you can set expire for token.
When a user registers, you would need to generate a JWT like you're doing now. That's OK. You don't need to save it to the database however. You didn't ask but I assume that the password should not be stored in clear text. You can use something bcrypt to encrypt before saving it to the database.
When user tries to login with correct credentials then i will send the response with stored token
Yes, that's correct way to do.
Then at client side(In my controller) i am using the localstorage to store the token so that i can send the same token for each and every request sent by the client.
Yes, on the client side, you can save the JWT to local storage and send it in subsequent requests to the server.
Now your bullet points:
So that you won't have the same JWT each time, you can include an "exp" claim in the payload (I'm assuming you're using something like jwt-simple to generate a JWT). Something like:
var payload = {
sub: account.username,
exp: moment().add(10, 'days').unix()
};
var token = jwt.encode(payload, "secret");
You don't need to store the JWTs in the database. In some cases, the token issuers (the authorization servers) are not the same as the resource servers. The resource servers only receives the JWTs in a request but there's no way for the resource servers to touch the database used by the authorization servers. Side note: If you eventually need to support refresh tokens, i.e. the JWTs that you hand to the clients will need to eventually expire, then you can store the refresh token in a database. Refresh tokens are not the same as JWTs (access tokens). The complexity to support refresh tokens will increase.
Local storage is not where you store passwords, but it can be used to store JWTs. For that very reason, a JWT must and should expire after a certain time.
Not sure what you mean by saying you check both client side and server side. When the client needs to access a resource (again it's fair to assume that the resource server might not be the same as the authorization server), the only thing that the resource server is passed is the JWT. Anyone can decode a JWT. For example, try to paste your JWT on this site http://jwt.io/. That's why a JWT should not contain any sensitive data. But if the resource server knows the secret that the authorization server uses when it encode the JWT, the resource server can verify the signature. Back to your third bullet, that's why it's OK to store the JWT in local storage of the client.
Update I'm updating this to answer to some of your questions in the comment box.
User clicks on 'Login' button triggers the Angular controller to post a request to the server, something like:
$http.post(url, {
username: $scope.username,
password: $scope.password
}).success(function(res) { ... })
Server receives the POST request, it checks username/password, then it generates a JWT, and sends back to the browser. Note that it does not have to save the JWT to the database. The code would be something like
var payload = {
sub: account.username,
exp: moment().add(10, 'days').unix()
};
var token = jwt.encode(payload, "secret");
res.status(200).json({
token: token
});
Back on the client side, in the success() callback above, now you can save the JWT in local storage:
.success(function(res) { $window.localStorage.setItem('accessJWT', res.token) })
The user is now authenticated. Now when user wants to access a protected resource, user don't have to provide username/password. With the JWT which can be retrieved from local storage, the client can now put the JWT in the Authorization header of the request using the bearer scheme, and sends the request to the server. In code, it would like:
headers.Authorization = 'Bearer ' + token;
The server receives the request. Again, this server receiving this request does not have to be the same as the server which generates the JWT above. The 2 servers can be in 2 different continents. Even if you save the JWT above, that does not do any good to this server which can not access the database where the JWT is stored. But this server can pull out the bearer token from the header of the request, validates the token and carries on with the normal tasks.
Hope this helps.
You do not want to store the JWT in mongoose because it appears in headers when logging in. You first generate a token then hash it using a module like crypto.
There are different ways to do this and they all use Passport which handles the tokens. Here's an example project Satellizer
I would recommend you generate the angular-fullstack project. Then go through the server/auth folder and the client/account folder. You will see how to securely handle authentication in a MEAN based app.