Is there any way to keep server side sessions in node js for requests coming through mobile applictions, Or it is in a way compulsory to use other methods like jwt?
As we do in Web applications, i.e Store the user information in the session on login and use the same information for later api calls.
Yes, there is and the simplest solutions is to use JWT, you can implement jwt authentication in you node.js server with any approach you want like: passport-jwt, express-jwt,... or even yourself with just jsonwebtoken npm package.
then for keeping mobile application authenticated with server, store the jwt token in mobile local storage and when app is opened just check the storage for if the token is exist or not and when there is jut add the token to the header and practically your mobile app keep a seesion open with server.
and for more information about jwt i ask a question about difference between session and cookie that might help you:
Authentication: JWT usage vs session
Related
what's a common approach of storing user sessions with Nodejs+Express and Firebase auth? I have Android and Ios app that I'd like to use the same logic on (later web as well), so I'd get the JWT token. I'd like to use that token as authorization for requests. Also I'd like to keep the user sessio and not require them to relogin again. I am not sure how to go about this, all of the Express Session resources I've found were on topic of web and cookies. I've stumbled upon MongoConnection a library for Express that presumably stores the sessions in the MongoDb, but how does the session work with non-web requests? Can anyone help me clarify this, I am aware that I am missing the point here as there is certainly an easy way to verify incoming requests and also have a session for the user to not have to login everytime.
Preferably I'd like to have an easy way to have endpoints that require JWT token access. Besides that also have a session of sorts. There is a function to verify tokens in the Firebase Admin SDK for Nodejs but it seems really weird to have to check the token manually in every request.
I treat sessions on the backend and front end entirely separately as I predominantly make RESTful apis. On the front end you can handle sessions however you like, e.g. you can start a session when a user authenticates with firebase auth, and set the user role maybe based of attributes on the firebase auth user. Use cookies, do whatever you prefer.
Then on the backend, on every endpoint just decode the token, verify it, check that the user has access to the resource they are requesting etc. Its common to write your own middlewares so that you dont have to repeat the decoding code. For further info on this approach, this might help. Its not weird to check the token manually on every request, its common practice to guarantee the authenticity of the request. Hope this is of some help.
To sum up, treat your front end session entirely separately from the backend. On your express server on the backend, on any protected endpoint decode and verify the token to determine if the user has access to the resource.
Backend sessions with firebase are a bad idea (due to it been serverless), its better to create a stateless restful api.
I've a backend RESTful API built in NodeJS and a front end application in React JS(NextJS), both hosted on AWS. The client and server communicates using JWT token.
I want to make sure both the client app and server side app are highly secured.
What i've done:
I'm using HTTPS for both client and server
Whitelist the client react app IP address so only the client react app can talk to the server app. This was done in AWS security group
Use cors in my server Node.JS application, to whitelist the client IP address again as an addition to No. 1
Use AWS WAF to secure the backend NodeJS application,
Use helmet in the NodeJS server backend API
Make sure the JWT token only last seven days, it'll be invalid and the user needs to login again to get a new token.
Answers i've looked at and used:
How to secure client app (react) and API communication
According to: RESTful Authentication i'm using Token in HTTP headers (e.g. OAuth 2.0 + JWT), this i sent for every client request
Using a refresh token: Refresh Token Jsonwebtoken
What i'm concerned about, and i need some help with:
1. Since the JWT token is how the server validates the client, is the JWT communication secured? Are there other steps i can take to improve the JWT security?
2. Is this application architecture secured enough?
3. Is there anything else i can do improve it's security, as i'm really concerned and want to make sure it's very secured.
4. Should i encrypt the JSON payload sent from the client to the server? because that's visible in any browser network tab under XHR, i'm sending username & password as payload for login.
I'm mostly concerned about security because i've integrated stripe payment in the application, and i'm also storing some sensitive data.
Any recommendation would be high appreciated, this is my first time deploying an production app.
As of what you have done the application must be pretty much secure.... except i would like to add a few things....
Make sure that the tokens have expiry and use refresh token to issue new tokens. The jwt stored at clients could be vulnerable for man in the middle attack. (For more performance use redis to store refresh tokens... look more on this)
If you are using https, the request will be only visible to the client's browser and not to any sniffers in the network (check on this whether ure able to see encrypted payload in sniffing tools like wireshark etc... to validate the https uve used). So its not necessary to go for any more encryption. That would decrease the performance of the api server.
I'm currently building a simple Express API with a user authentication and some data to be stored. Right now in production I'm using passport-local authentication and a cookie session to authenticate users, but I heard that in production that is not really good.
Why are other authentication methods better and which authentication would be save, stable and scalable? Also what speaks against cookie-session? Is express-session with connect-mongo better and why?
I would take a look at this article from Tania Rascia. It covers using Express with JSONWebTokens (JWT) and OAuth with Cookies. It's a secure method and it all runs on the same server (backend and front end served with express).
I have been researching on RESTful authentication alot, and I still can't get a very clear idea, how can I design my web architecture. I have many questions that are unanswered.
I want my API to be served to mobile and web too and I am using Express v4.
I don't want to use Basic Authentication, as many posts have suggested as a simple way out, or I can use the Passport middleware, but I want to use token based authentication or something similar or better,and I want to make my authentication, so I could understand better, but I am not sure how can I achieve it.
I will simplify my intended authentication architecture below:
Registration of a new user
Client side
Post username and password to server
(I know if you want to make the connection secured is to use https connection, or else I will expose my credentials, or you got any other options besides https? or else I will need to use the public and private key with timestamp and hash my credentials before sending to server? How can i do this? Is there any other better option?
Server side
Hashed the password using salt cryptography, and stored the hashed password and salt, then generate a token ID and sent to the client, and the token ID is stored in sessions or using the REDIS database?
Isn't that using sessions violates REST again? But, if I don't use sessions, how can I store the token ID and compare it with the client side?
Client side
Since now I have the token ID, how can I store on client side?
Should I use cookie? If yes, will this violate the RESTful? And how can my mobile application store the cookie too?
What other options can I have besides cookie? I can't think of any.
Authorizing API
Client side
Now, I have the token ID, I will place this in the authorization header each time I would like to make a request to the server.
Server side
When a request is received, the server will check the token API, and compare it with the session token, if it is true, request allow else reject
Is this a standard way for Express application authorization?
I am sorry for the lengthy post, but I feel that I should really master the authentication and authorization because it is important. I do hope someone can correct my misconception of REST authentication and answer my questions or suggest me a better way to do it.
Send the user credentials encoded over https
To compare the token at the client side you can either keep it in map or in Redis store corresponding to user id and match it to consider user authenticated. It does not kills the significance of Rest as in Rest as well authorization tokens are sessions only which after expiry
Express does not have any specific or standard method of authorization , it only enables you to use any db in backend to perform authentication and authorization as required by your application
Your solution is the use JWT tokens for your authentication .You can read more about JWT at https://medium.com/dev-bits/a-guide-for-adding-jwt-token-based-authentication-to-your-single-page-nodejs-applications-c403f7cf04f4
With JWT tokens you can have a token base auth system with no sessions UID at cookies , but you have to implement logic to handle tokens that have sign out something like blacklist tokens.
Sorry for asking open-ended architectural advice.
What's a good design pattern for handling authenticated login sessions in a web app using connect-redis and passport.js for session management and authentication?
Should the login service provide a temporary token?
Should that token be persisted to the session store or passed through http GET?
How should I provide a common authentication architecture for both the client app and the API services it is built on that themselves could power other apps?
Why don't you use expressjs framework. It has a beautiful session module, with persistent session cookie. The sessions can either be saved into redis,mongodb etc.