There doesn't appear to be a really clear explanation of what an authentication strategy is and what role it plays.
This is what I think it might be so far(please correct me if I'm wrong):
It appears that for each login type there is a strategy(google, facebook, local etc).
The strategy gets created then added to a passport object and the passport object is then used to sign a token which is used for a (un)specified time. However the username and password are not verified through jwt or passport initially.
An authentication strategy in passportjs isn't really that complicated -- it basically handles the 'authentication' of the user.
So, for instance, with the Passport LocalStrategy, it will take in a username/password, then check the database to see if those credentials are valid or not.
With stuff like the Google Login / Facebook Login Strategies, they'll simply use the Google Login API / Facebook Login API to redirect a user to Google / Facebook, have them accept the desired app permissions, then retrieve the resulting access token from the provider.
Strategies exist so that you can easily make passport authenticate a user in a number of different ways.
Related
Im trying to use passport to use OAuth2 to login but I'm not fully understanding the documentation.
My end goal is to have the front page of my website to have multiple login options via twitch/google/facebook that all lead you to the same account if you email happens to match. (example service that does this: streamlabs login) I want to do this without using a username and password so each of my DB docs only have a unique ID to identify each account and subsequent objects keys as twitch/google/facebook containing API tokens and emails.
The part I dont understand is how to tell passport to identify the same DB doc when the user is logged in, from what I think it could be is the callback for the passport strategy registration where you use done(null, profile) to tell passport they have been successfully authed.
Would I have to change profile to the unique DB doc ID to make it universal accross all auth methods?
Turns out I was right, was hoping for an answer earlier before I had to change a bunch of my code
I did jwt authentication in my previous projects but never worked with oauth/passport auth before..
it's been 3 days i have been learning about passport strategies and i have implemented google+ strategy.
I got new project and this project requires to let users signup/signin themselves with google or facebook or with signup-form using firstName, lastName, phone number and password..
Very briefly in jwt server sends a token to the client and then client sends that particular token in the request header back to server to have access to protected routes.
In passport google strategy a cookie is saved in the browser and is send to server on each request.
What i think is
i cant use two different approaches in one project.. like if i use jwt for signup form and cookie for google strategy how am i gonna protect my routes then? with token in headers or with cookie in browser
Now my question is
how can i use both in the same project?
In google strategy should i generate jwt (token) for client in serializeUser() or somewhere else or what else is possible?
Or should i save jwt token in a browser cookie like passport?
I presented things very briefly, i hope you get it what i'm trying to do here
i cant use two different approaches in one project.. like if i use jwt for signup form and cookie for google strategy how am i gonna protect my routes then? with token in headers or with cookie in browser
You can. Cookie is just a transport mechanism for data between your browser and the server. You can store anything in it (up to allowed size limit) meaning that you can store JWT in a cookie (rather common practice especially for server side rendered single page apps).
You don't even have to develop a custom solution because this is already provided by passport in passport-jwt.
In the scenario where you require to signup the user using predefined fields you could use something known as Local Strategy which is present in passport.passport-local
I have a Node.js application that offers several different routes in front of MongoDB. I need to make sure that only authenticated requests can access these routes.
Ideally, I want to set it up so that a username and password comes in to the API, and in a response we give them back a token. I don't mind managing the tokens inside MongoDB myself, but I need to make sure that the token we give back can make authenticated requests. I don't want to force the user to send their credentials each time, just the token.
I've read for a few days about passport, and there's currently 307 strategies. Which strategy am I describing here?
Which strategy am I describing here?
You are describing a Local Strategy.
As per their description:
This module lets you authenticate using a username and password in your Node.js applications.
I don't want to force the user to send their credentials each time, just the token.
Passport auth strategies just provide various ways to authenticate (or in simple terms login) the user, not how to persist that login. Login persistence is usually done with user sessions.
One way you can solve this is to combine the local strategy with the express session middleware. Combination of the two allows for a fairly simple auth system that requires the user to login once and then persists the session.
In a typical web application, the credentials used to authenticate a user will only be transmitted during the login request. If authentication succeeds, a session will be established and maintained via a cookie set in the user's browser.
Each subsequent request will not contain credentials, but rather the unique cookie that identifies the session. In order to support login sessions, Passport will serialize and deserialize user instances to and from the session.
PassportJS docs give an example how to achieve this.
For this you should prefer generating JWT tokens for a the login and then using the token to always authenticate user actions.
Following steps are need to implement this style of token login system
generate token on login
verify when token supplied and use the decoded data to identify user
use should proper middleware in order to protect your api.
Here is a link you could follow:
https://scotch.io/tutorials/authenticate-a-node-js-api-with-json-web-tokens
I'm trying to build an authentication service with express.js, but I didn't catch the idea of authentication modules yet.
What's difference between passport and oauth middleware? Are they dependent of each other? Is useless to have the BearerStrategy without an oauth server to generate tokens to the BearerStrategy validate? Am I on the right way?
I've read about oAuth2 and Its authentication flow, but I'm still lost with this uncoupled code.
I'm trying to build the Resourse Owner Password authentication with refresh token for my AngularJS frontend communicating with the backend API, and I'm facing with many combinations of password.js strategies (Basic, Bearer, ClientPassword) with oauth2orize on the other side.
So, I'd like to know a very simple explanation of how authentication works on NodeJS. At really I know that Express is not inventing a new way of how authentication works, but the modules are too unobtrusive that I need to understand the base of how It works to achieve them working together.
Passport is authentication middleware.
OAuth is authorization middleware.
To understand the difference:
Authentication is the process of ascertaining that somebody really is who he claims to be.
Authorization refers to rules that determine who is allowed to do what. E.g. Bob may be authorized to create and delete databases, while Bobbette is only authorized to read.
In other words. Authentication is your username + password. Authorization is what you're allowed to do.
Passport will allow you to authenticate the user before allowing access to your API. It does not (directly, it's possible) allow to check if a user is allowed to perform an action after authentication.
Check this Wikipedia for more on Authentication vs Authorization.
What OAuth does that Passport doesn't, is that it allows users to grant a service access to their personal information. It also allows users to allow or disallow certain privilages (scopes in OAuth).
Do note that there are a lot of OAuth flavors. The most common is the version with authorization grant types seen when authorizing with Facebook or Google. But there are many others including the Resource Owner Password strategy you mentioned.
I'd like to be able to sign into my node app using LinkedIn, an email and password, Facebook, and possibly others. I don't want to use sessions/cookies. Instead, I want to use a header with a token for authorization -- jwt or something else. I'm open to anything here.
My question is the same as the one asked here: https://groups.google.com/forum/#!topic/passportjs/DJZZGKXDLsk -- I want the users to go through the following steps:
User comes to my site
User logs in through LinkedIn
User is redirected to post-login on my site
User can continue to interact with my site using header tokens (not session cookies)
Passport for LinkedIn OAuth2 more or less works for what I need it for, but the only problem is that it looks like this is entirely geared towards using sessions with cookies. After the callback url is hit on my server, I don't see a way to get tokens back to the client securely.
It also seems like I can use the LinkedIn frontend JS SDK to have users authenticate and post-authentication they can make a POST request to my server and at that point I would be able to confirm authentication with LinkedIn and respond with the tokens I create for authentication in the POST body. I'm not sure if this is recommended or secure and I don't love the idea of having the LinkedIn API key in the frontend JavaScript either.
How can I use LinkedIn OAuth2 to authenticate to my site and keep the authentication without cookies/sessions?