I don't understand how serializing and deserializing work with express session.
When I installed Express-session it said that I needed a serialize and deserialize function:
passport.serializeUser(function(user, done) {
done(null, user._id);
});
passport.deserializeUser(function(id, done) {
User.findById(id, function(err, user) {
done(err, user);
});
});
Server.js Post route from login form:
router.post('/login', passport.authenticate('login', {
successRedirect: '/home',
failureRedirect: '/',
failureFlash : true
}));
My question is when the user attempts to login from the form on my HTML and hits the endpoint as specified above '/login', is this where express session comes into play? So express session will create a cookie with a session id as user._id as specified in my serializeUser function and it will give this cookie to the client? So now when the client makes any subsequent requests to that same server at the endpoint '/login', it will automatically call deserialize user without going through the passport middleware that is provided in the router.post('/login', ...)?
I am not sure when and where these two serialize functions are called and how express session actually uses them? Any clarification would be appreciated.
To understand this, we have to go through the basic idea of what is a cookie and how does it work?
Cookie:
It is collection of data that is stored in computers browser and is sent with every request to the server in request headers and received by the browser from server in response headers.
What is need of a cookie?
Now we know that http requests are stateless (means every request is a fresh request for server that is for example if u login to some website which is the first request made by you and then u make a second request to display your profile then at this point server does not know who are u), so for authorisation the server needs to know who u are and this information is stored in a cookie.
When u log in , ur credentials are send to the server and server sets these credentials in cookie which is then send to the browser , and after that every request u make , that cookie is send back to the server which is then verified and hence allowing u to access the relevent information.
Now a point should come into your mind that are cookies safe for storing users credentials?
The answer is a big NO , as as the user can manipulate it at his/her leisure . Yes a cookies data can be manipulated anytime , so its not safe to store user credentials in cookie , so whats the solution ?
Here we come to idea of sessions.
Sessions:
Session is an object that is stored in server side instead of browser and hence remains safe. Now how it helps in authorisation , see:
When user signs in , request is sent to server and an object session is made which stores the credential of users and this session object is given a unique id which is encrypted using that serializerUser() function and this id is stored in cookie and which is then send to browser. Now the user if try also to manipulate it , he/she cannot as the cookie just contains the session id which is encrypted and can not be decoded by any means.
And then this cookie is send to browser with another request which then goes through deserializeUser() function and gets decoded which matches with the stored session id hence verifying the user.
Related
I am using an express backend restricted by passportJS, I noticed that the default setting seems to be sending the user information in req.user (including the password) for every request done after a log in. Are these additional properties sent with a request called cookies? And is including the hashed password safe?
The user object does not contain data from the request.
It is stored internally and associated with the token (be that a JWT, session ID or whatever) that is sent with the request.
I am trying to use routes to help server pages from a nodejs server based on a user being logged in. I am trying to take the login session details from the client side, and pass them back to the NodeJS server to be used in a middleware function for checking authentication.
How do I go about adding a variable to a request for a NodeJS route from the client side?
middleware.js
function loginRequired(req, res, next) {
if (!req.user) {
return res.status(401).render("unauthenticated");
}
next();
}
module.exports = { loginRequired };
server.js
app.use("/dashboard", middleware.loginRequired, mainPage);
The desired result would be, user clicks "Login", some variables are sent back, as well as the request to that route, the variables (i.e req.user) are used to check authentication.
You can send the variables in cookies, and use cookie parser, before your middleware. It provides parsed cookies.
For example, you can send a User variable in cookie, and then in your middleware use req.cookies which will contain your User variable.
Alternatively, you can send data in a POST request and use body-parser to do the same thing. But for authentication purpose, you should use cookies.
Before I have to say that I've found some post related this question but not fully answered.
So I implement a nodejs REST API server, DB with mongoDB, however about authentication i understand the idea, with jwt token it work perfect.
/api/login
you get response with token. now you can request resource with this token
for example.
api/posts/:user_id
get all your posts...No problem! query with mongoose findBy.. bla bla!
so for authorization in this case it's easy, check for query param user_id is equal to token (token parse with user_id). boom resources is secure.
but in case that I have some resources they're not reference by user_id, What is best practice to protect this resources?!
example
api/settings/:settings_id/emails
imagine that I know the setting_id of other user, and i authenticated with token. so how server will know this resources is not allowed for me?
First, you should do more to protect the token in the first place. When you issue a token after a user logs in you should store their token on either web storage like sessionStrorage if https is enforced or use an httpOnly cookie (You can add a user-agent/geoip fingerprint in addition to the user_id upon signing this token to add an additional layer of security). Then, when a user makes a request for a protected resource, you can match the fingerprint and user_id you signed the token with to the user they are making the request in behalf of.
You could use something like passport-jwt as a middleware in express to require authentication on routes. In passport, you define an extractor handler that basically tells it where to look to see if the user has a token and if they do and it validates it adds the req.user property that you can use on subsequent requests to determine the user_id of the token bearer. So basically with this approach, you know the user_id on every request which lets you compare that with the user information they are requesting.
app.post('/settings/:settings_id/emails', passport.authenticate('jwt', { session: false }),
function(req, res) {
res.send(req.user.id);
}
);
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.
I am trying to create a login procedure with the Parse and Facebook Javascript SDK. The authentication works without a problem on the client side, but I need to access the user object (created by Parse SDK) on the server side too. How can I do this the most elegant way? I thought when I log in into Facebook via Parse a cookie is set and so I can access the user object from the server. Or should I do the login process server side? Any recommendations?
I'm facing the same problem. Turns out that you can use either server-side auth or client-side auth. You cannot mix-and-match the two. Have a look at their official blog post about sessions.
var parseExpressCookieSession = require('parse-express-cookie-session');
// In your middleware setup...
app.use(express.cookieParser('YOUR_SIGNING_SECRET'));
app.use(parseExpressCookieSession({ cookie: { maxAge: 3600000 } }));
// Making a "login" endpoint is SOOOOOOOO easy.
app.post("/login", function(req, res) {
Parse.User.logIn(req.body.username, req.body.password).then(function() {
// Login succeeded, redirect to homepage.
// parseExpressCookieSession will automatically set cookie.
res.redirect('/');
},
function(error) {
// Login failed, redirect back to login form.
res.redirect("/login");
});
});
Also, I came across this when digging through the doc:
You can add Parse.User authentication and session management to your
Express app using the parseExpressCookieSession middleware. You just
need to call Parse.User.logIn() in Cloud Code, and this middleware
will automatically manage the user session for you.
You can use a web form to ask for the user's login credentials, and
log in the user in Cloud Code when you receive data from this form.
After you call Parse.User.logIn(), this middleware will automatically
set a cookie in the user's browser. During subsequent HTTP requests
from the same browser, this middleware will use this cookie to
automatically set the current user in Cloud Code.
...
When you work with user data, you should use HTTPS whenever possible.
To protect your app and your users, the parseExpressCookieSession
middleware requires you to use HTTPS. For your convenience, we also
provide a parseExpressHttpsRedirect middleware for redirecting all
HTTP requests to HTTPS.