I need to enable authentication on my REST server, but I have some troubles in understanding,I think.
So, if I use some custom strategy, I need to take some credentials and checked it on some data-base, and if it's right credentials, return some token which user will use later.
Am I right? If yes, how can I connect my database and how data must look like for rest-server understanding?
You need to learn how to create custom passport strategy. If you want to validate the credentials stored in some database then, I think you might find a passport strategy for that database. You just need to provide correct COMPOSER_PROVIDERS arguments (you can check with the documentation of the passport strategy) and that's it. And I dont think rest server has anything to do with the way data (credentials) are stored in your database. It's the passport strategy which checks for your credentials.
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 have a bunch of questions about express-session and JWT in a project that I am building.
I have an Express API server that I want to protect using some sort of API key, to make sure only authorized applications can access to my data. JWT would probably get the job done. However I also need to authenticate users and restrict them from accessing certain parts of the data (e.g. role-based permissions) using express-session.
The frontend server would be a Next.js instance, which would save and use the cookies for express-session. The session would be stored in a MongoDB instance.
Would I be able to use both authentication methods in the same project? Would it be secure? Is there any easier approach to this? How could I implement the permissions?
Any help and tips would be appreciated.
JWT and Express-Session both accomplish the same thing. The difference is a browser does not allows a http-only cookie to be accessible through javascript. At then end they are both used for the same end.
The jwt should be related to a session of a user, therefore the users permissions are the ones that matter. These can be implemented in a DBs and related to the user. Does he has this permission or does his role has this permission is the middleware you would put on the routes.
In case of doing it with express-session, I would personally take the same approach.
Good morning/afternoon/evening!
Having recently started a little Project for myself, one of the first things I wanted to do is the Login/Authentication and permission to access different routes/Authorization.
I am currently using:
NodeJS
Express
Passport (+ Passport Local and Passport JWT)
jsonwebtoken
The goal of my Server is to receive a Stateless Authentication/Authorization System because I aim to bypass the "Single-Threaded"-Problem and use Node's Cluster Module to spawn a Process for each Thread.
I have already accomplished a basic authentication via a JSON Web Token and am currently storing only the UserID, iad and expiry date in it.
Now I was thinking about adding roles to have an "easy" check if the user was allowed into certain routes or not, but there was where my problems started.
Assuming I add roles into the token, I can easily verify if I am allowed to access that route or not using the JWTStrategy of Passport.
But what if the roles have changed within the time the Token was issued, and the time the user tries to access a route he has no more permissions to? As of now, he would probably be able to still access that route because the JWT'S receive (obviously) no instant update of the roles.
Same goes for a banned/suspended user, he would still be able to use the site as normal, until the token expires and he needs to request a new one.
This until now reflects the strategy of not querying the DB after the login anymore for user information, since the JWTs are used to store the most critical data (Not user sensitve ones though).
Invalidating the Token could easily work via JTI's (TokenID in the Token) which are stored in the Database, and once the TokenID is said to be "banned" or anything, I'd simply not let the token authenticate anymore. But this adds a database call per API call...
For Roles/Permission verification, the way I see it right now as well is that I would not get around one Database call per API call to check for user rights.
I know that there are solutions like Node-ACL or CASL, but they are either In-Memory which I can't use because I would love to not rely on Memory because I am Clustering, or even Dockerizing my Application, and I don't wanna be "only" depending on Redis or MongoDB - I'd like my application to be pretty flexible when it comes to Databases.
I also know that there are Strategies like "Refresh" and "Access" Tokens, where the Refresh Token is long-lived and the Acecss-Token is short-lived (e.g. a Expiry Date of 15 Minutes) - Is this a suitable strategy? The Ban/Suspension or RoleChange would still not be instant. I could keep the Refresh and Access Token in the Database and Invalidate the Access-Token once critical data of that user changes, and let the CLient/Website figure out that the AccessToken is gone and require a new one... But this seems like a huge overhead to me...
Summary
I am using JsonWebToken to Authenticate the user. My problem is that I am not getting around a Database Query per API Call of the User because I don't have critical info always updated in the JWT (User Banned/Suspended, Roles).
What is the best thing for me to do in this Situation?
I have one issue, where I would need some inputs.
In my current application, using Node,Express I have a auth token which is generated by third party post login. I need to save this token on Node layer, as I cannot expose this token on client side.
Is there a better way to save this token on Node layer for each user specific once user gets logged in into the system and invalidate if user logout.
Please note that, there is no authentication done on node layer, it all verifies on some third party API's and that API generates a token.
So my question:
How I can save this token on node level.
Is there any way available by which I can save token for each user,Currently I am thinking to use Redis as it is just key value pair.
If I compare Mongo Vs Redis, which will be a better option?
Is there any other way around to solve such scenarios?
For example If I will save this on client cookie, how I can make
this token more secured, so that client cannot read this token.
This is not a complete answer since I do not know whether there is a secure approach to save a token on a cookie. I think that using Redis database is the way to go for its greater performance compared to MongoDb since you would be storing key value pairs as you stated.
I'm building an anonymous app like yik yak and wanted to ask what is the proper passport strategy to use to authenticate. I'm currently using the device's UUID. I looked at the local strategy and that requires a username, password and it's session based (i'm implementing token based so my api isn't left open).
That said, would I implement a passport-http basic strategy and disregard the password altogether and use just the UUID as authentication?
Please help! I'm not entirely sure how to approach this issue. I do know, however, that I don't want the user to login, ever.
Thanks!