I am not familiar with user authentication in Node.js, now I am trying to create a website with a login system. I have managed to make it work using the code snippets from the website, but I don't really understand why we need the passport.js as a middleware to do the authentication.
Registration:
Let's take passport-local as an example, when we are using the passport middleware, we basically is trying to create a new document in the database, then can we do it without passport, such as using the MongoClient directly, with checkings of duplicates, and store the password after encryption.
Login:
We can simply check the user's email or username against our database, and then check the password after email or username is matched. This, as well, can be done without passport. After user identity has been confirmed we can use the express-session to store the session in the cookie for login persistence.
A video about the process that I described above can be found here.
I understand that there must be some very important functionality that I neglect, but after browsing many web resources, including stackoverflow, youtube, passport.js's docs and many others, I still didn't understand what does passport.js do and why we need it.
Apologies in advance if the question seems silly.
To me it's unnecessary.
It's not saving me any work. I have to write the configuration, the callback, and the user schema. To me, it's just easier for me to just write a middleware for that.
And I don't see there is any security enforcement I am getting cuz I am writing my own verify callback anyway.
So, I don't see any reason that I should use it.
Passport is a middleware for express.js. It supports various login types, Basic, Token, Local (username, password), OAuth, OAuth2, etc. We can combine these to allow users to authenticate by signing in with Google, FB, or whatever service with very minimal amount of code. We can also use this to combine external auth services so users can choose to login with one of the selected Strategies, e.g. Google, Twitter. It's much quicker to use passport for authentication than to build one yourself from scratch. This is why we use passport. You don't need passport, it just makes developing quicker. Read more from their website => https://www.passportjs.org/
Related
We have a web app that caters to a small set of users that are guaranteed to have an account on Office 365.
To save them from remembering one more password, and to use Microsoft's infrastructure for OAuth, we decided to allow them to login using their Outlook credentials.
It is a react app, we are using the msal library and we have successfully been able to receive the accessToken from Microsoft. (Thus, authenticating the user's identity.)
What I am not confused about now is what I should do with that token:
I need to have my own User database. What information should I store in it? Should I store the access_token as well?
How do I verify the user's identity on my backend server?
Basically, what is the ideal way of managing this kind of a scenario? Wherein a third party authenticator is used (and solely) used to confirm the identity of the user and get the name, profile image and other things only.
Any references to existing workflows or an explanation of the steps involved will be highly appreciated.
I'm currently working on my friend's (who is a photographer) portfolio website using the following technologies:
Node.js
Express
MongoDB and Mongoose
ejs
I'm a beginning developer and have been struggling for a while now with authentication. I know how to use the passport package to create an administrator user, but since I don't want to implement a user system for a portfolio website, I'm not sure how I should go about making an admin.
The admin would be my friend, and he and only he should be able to see express routes meant for replacing pictures, uploading them, and in short just making post requests to the database. I know I should probably use some form of middleware like with the Passport package, but else than that I have no idea how to go about this.
Thanks in advance!
You can use HTTP Auth for this purpose, check this NPM Module
What happens is, you will define a custom username and password, and use the package as a middleware for your routes, now whenever a user visits the page, the browser will automatically show a popup asking for username and password. In this case, you will not need to implement a user system.
A similar question and answer is posted here
I need to authenticate users in browser (not mobile app) using AWS Cognito with username/pass, not FB/google IdProviders.
There are a lot of docs but they seem to be separate blocks which either incomplete, do not fit the requirements or do not fit each others :(
I created Cognito User Pool, then Identity pool and tied the userPool to the idPool, then I stuck. Do not know which library to use and how to use it.
The closest I find are:
https://aws.amazon.com/sdk-for-browser/ but my experience is not enough to convert their FB samples to not-using FB
https://github.com/aws/aws-amplify but using this lib I'll have to study React/Angular from the very beginning (I'm not a front-end developer, sorry) and I have no clue how to convert their npm-based samples to front-end javascript (npm is for NodeJS thus back-end, isn't it?).
All I need is plain html form with username/pass, send the request to Cognito and a way to check during the next page load whether the password was correct. If it matters I will use AWS Lambda as back-end for processing future tasks.
How can I do it? Is there a tutorial/doc for my case?
Thank you.
You can use AWS Cognito UserPools Hosted UI for your use case. The simplest form of authentication is using the Implicit Grant.
For more information about setting up Hosted UI refer Add an App to Enable the Hosted Web UI.. This will create a UserPool where users can register them self (If you plan to restrict this, you will need to either add users using the AWS Web Console, Cognito UserPools or using their SDK)
The steps are as follows.
Set up Cognito Hosted UI and register your application domain. This will create the login/registration pages for you where each of this will have a unique URL. What you have to do is, if the user is not authenticated (Let's discuss how to detect it later), you need to redirect the user to the Login page.
In the Login URL, you also need to specify the redirect back URL to the application so that after a successful login, Cognito will redirect back the user to the application providing the token in a query string.
You can then access the id_token from inside the application and use it for querying the backend.
Since the id_token is a JWT token you can verify it at your Backend using the public key available at the Cognito token endpoint.
To implement the JWT verification, you can also refer Cognito JWT Token validator NodeJS module.
Note: If you need to keep the user's logged in for a longer time period (Than 1 hr), you might need to use the Code Grant flow which will return a Refresh Token, which could be used to retrieve new id_tokens programmatically.
I have a web tool developed, which uses node.js and socket.io. it's a one page website and uses node.js for getting data from social media website and display on the same page. I would like to add a site specific login system for the website but don't want to use 'Express' or 'Passport' as it adds lots of overload to the website while it is not needed.
I am newbie with node.js and would like to know if I need to have a login system made with node.js to maintain session of the logged in user?
Note: I need to maintain session to log user data such as login time, search query and may be heatmap.
Thanks in advance. If needed I can explain specific part of the question in detail.
Using something like Express or Passport (or at least some of connect's middleware) will definitely be easier in the long run (if your app grows), but if you want to go the 'manual' route, here are some starting points:
Cookie Parser: You won't want to send the auth details with every request as a parameter, so you'll want to put the session details in a cookie. You can set cookies manually using headers, or with a node module that wraps the API neatly.
Session Storage: You can put all the "login time, queries and heatmap data" in cookies, but it would be neater to just send a session id in the cookie in each request and save the other data server-side in a database. Options are mongoose, redis, etc.
Since reading the source is very educational, go read connect's cookieParser and cookieSession. It's not a lot of code and the API docs include the actual source, so it's very easy to learn from. Enjoy! :)
From how you are phrasing this question, I believe the overhead from using Express modules (Passport or similar) is the least of your worries ;-)
First you need to figure out which mechanisms you want to use.
For authentication, will you use a username/password combo, or will you be using a third party service like Google, Facebook, Twitter etc ("OAuth" like)? Unless you use some third party service, you also need to handle registration (and possibly verification of email address etc). Even for username/password combos, will you roll your own or use the browser based "basic-auth" mechanisms?
After authenticating you need a session mechanism to store some session token to recognize (and verify server side) that you have been authenticated. They are typically stored in browser cookies, which can easily be persisted for as long as you need, and are verified with each relevant request with tokens in a database on the server side.
And finally, you need a logout mechanism and a "I forgot my password" procedure (which may very well be manual initially...).
If all this is fairly new to you, I suggest trying to use something ready-made first (you mention Passport yourself), and then when you've mastered the basics, feel free to replace it with your own. The "upside" of using Passport or Everyauth is that they cover a lot more options that you realistically will be able to write yourself, so once you've adapted your system to use one of those, adding Facebook logins and similar will be a lot easier (somebody already figured out most of the stuff for your).
To be honest, most of the modules that handle such things in the Node ecosystem are fairly thin wrappers on top of whatever solution you decide to use, so the overhead will most likely not be substantial and you will most likely need a good understanding of the issues anyway to use them. At the other end of the spectrum are ready-made-systems like Drupal etc where everything just works, but then you're somewhat boxed in as far as making your own system.
There are use-cases where rolling your own from scratch is absolutely necessary, but there's nothing stopping your from doing this later when/if necessary (and after you've mastered the basics with the help of code that others wrote).
Best of luck!
When I use Facebook's JS SDK to authenticate my app (using FB.init method) all I need is my App ID. It does not require my app secret and/or app key.
However when I used PHP SDK, it required my app secret (atleast the example I used to learn used the app ID and app secret both).
Is it secure and recommended to use the JS SDK for authentication ? How really does the authentication flow happen with the JS SDK ?
Thanks,
Vineet
I'm looking into how secure the authentication is also - I think things have changed since you asked this q, so perhaps this information was not correct when you asked.
The new version of the JS SDK uses OAuth 2.0. This is well documented - check out the OAuth 2.0 site for details.
Regarding the issue of whether the SDK needs the app secret - I'm having a little bit of confusion relating to this. On the app server side, the libraries indicate that the JS SDK signs the cookies using the app secret (see the function get_user_from_cookie in the facebook-python sdk) - however, it's completely unclear to me how the JS SDK can know the app secret. I'm guessing that it can obtain it dynamically from FB when it talks to FB directly in the authentication process, but I'm not sure.
(Edit: I think that the JS SDK gets the cookie signed with the app secret directly from FB - the JS SDK never knows the app secret).
Not fully answering your q, but perhaps shedding a little more light on how this works.
Another issue to be wary of is not to use the FB user object you get from the client for anything on the server side. This is because it would be really easy for someone make a script which instead of calling fb.api '/me' would send a "fake" JSON user object with another users ID to your app. If you're doing any kind of server side processing of the user then you really need to do some kind of server side authentication as well I think.
It's NOT safe, this is why you have the "Verify Fields" and "Not Verifying the Signature" paragraphs in the Advanced Registration document:
When you request facebook data, we
verify the form fields before
packaging them up in the
signed_request. This lets you assume
that all the data is genuine and saves
you from having to verify things. The
one problem that could arise, is a
smart attacker could change the form
fields and submit them to you, thereby
giving you unverified data.
Read that document for more information, I've also wrote a tutorial (an introduction about the plugin) and showed how to handle the fields attribute coming from client-side.