I have a NodeJS Express application with Passport.js email and password authentication. Users either reuse passwords from other websites or fail to remember them, so I want to do away with user passwords entirely.
I want to implement one-time passwords by email or text message. When a user signs up or logs in, they would receive by email or text message a 4-digit code. Adding that which authenticates them and places a cookie for a persistent session. The Passport docs support password and OAuth authentication but I could not find a one-time password strategy.
I could implement it by changing the password validation method and I wonder if it already exists out-of-the-box. Does Passport or another NodeJS library implement one-time password authentication?
Related
In my case, I have a React app (using Next) that need to use an API provided by a node / express / mysql app.
My idea was to have an endpoint (/login) to provide a JWT Token based on user / password (that check the user in the database and create token based on the id of the user) and then use the JWT token to use the API endpoints (those token are stored in the mysql as well). But in order to do that, and because there is no form, I would have to store the credentials (user and password) in the client side app and therefore would be readable by anyone. Am I doing things right and if not, what are the other options to securely make the client side APP use the API endpoints ?
The React and the Node / Express are on the same domain and CORS is set by default by express from what I read. Also, HTTPS is activated.
generate web token
do encrypt using becrypt npm
store it in DB and cookie in the client side in encrypted form while the first-time user is login
create on middleware which directly accesses your cookie and check-in your database and make your user login for a long time if your cookie token match with database token. like below example
sample project : https://github.com/karenaprakash/books_review.git
refer to this full application
visit this project. I hope this will help you.
Basically the JWTs allow you to avoid using sessions completely & to not store them in DB, a JWT is like a passport that you give to a user, that states his (ID, maybe username for example), role & any other data (that is insensitive if someone sees), so you should never store a password in a JWT
Security of the JWT basically lies in the fact of that no other entity can imitate it (if you use a strong key for signature) & although possible to encrypt your JWT, you don't have to encrypt it as long as you don't put sensitive data in it. I think you should try to have a look on this website to see how the signature protects the authenticity of the JWT
So you should make the /login API, this will check your user credentials & then give him the JWT (that states he is user 'joe' for example with the role 'admin') & then you check & verify this JWT in your filters to authenticate & authorise the user for the actions in your webapp
To get the JWT, a user must provide his credentials to you in a HTTPS connection, which will make the connection itself encrypted, thus protecting his credentials from eavesdropping or man-in-the-middle attacks
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.
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 have a chrome extension which allows users to exclusively login with google and no other provider.
In my (node + couchdb) backend I need to construct a user account from the auth Response provided by google's oauth2 api. I was thinking about using a hash of the id_token as a password after verifying the token using the tokeninfo api
I realize that the id_token changes from time to time. In that case I was hoping to update the user's password automatically.
Here is the flow I had in mind:
1) User signs in on the front-end and gets an id_token from google
2) Id token is sent to the server and verified using the tokeninfo api
3) If verified, a user account is created with a password being the hash of the id_token.
Do you see any security holes with this flow? If so, what are the alternatives?
It is probably annoying to change user passwords all the time, and this ties your authentication too much to google. What if you want to implement password logins in the future, etc.
I would recommend to use something like proxy authentication instead.
http://docs.couchdb.org/en/latest/api/server/authn.html#api-auth-proxy
make sure to set
[couch_httpd_auth]
proxy_use_secret = true
in the config.
On a side note: if you sync the couchdb password with external secrets like in the question, you should sign the password with a hashed secret that you control completely.
The nodemailer module (allows to send emails in a node.js app) supports XOAUTH2 authentication against Gmail accounts. Why would one want to use this for general purpose email notifications as opposed to just specifying the user: and pass: parameters in auth? I understand that the password is then stored in plain text, but it's never propagated anywhere. Also, the XOAUTH2 method seems to require a clientSecret: parameter, which should also probably not be made public. So what are the advantages here?
Similar question: how can I include authentication information in the app without pushing it into the remote repo? Is there a way to just ignore those lines with Git?
Using XOAUTH is useful when you want to send e-mails on behalf of your users (eg. as if the sender would be the user, not your application) - instead of asking their passwords, you can ask them to authorize your application through the OAuth mechanism. The resulting client secrets are known only to you, valid only for accessing the e-mail of the user, nothing more and the user can revoke these client tokens any time they wish.
If you do not want to send mail on behalf your users but with your own credentials, then there is no point of using XOAUTH.