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.
Related
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?
Here's my question. To access our app, the users must be invited.
This means, we use an admin web app to create the user account in Firebase and we send him an invite to download the app and use it.
Now the next phase, how can we send to the newly created user his credentials?
Our first idea was to use a temporary password. We could send the password by email to the user and ask him to redefine his password at his first logging.
His this a good idea? I guess it's not
Is there a better way?
Thanks for the help.
T
There is no way to prevent users from authenticating with Firebase Authentication. So instead of depending on pre-creating of the accounts, you should ensure that only authorized users have access to the data.
For example, when using the Firebase Database, you could keep a list of authorized users in the database:
/authorizedEmails
t4ncr3d3#hisdomain,com: true
puf#hisdomain,com: true
And then you'd check the auth.email variable against this list in the database's security rules.
Instead of pre-creating the account, you could then simply email the user an invite to the app. E.g. an email with a link like http://myapp.mydomain.com/signup.html?email=t4ncr3d3#hisdomain.com
Then when they click the link, pre-populate the sign-up form with the email address you sent the message to and call createUserWithEmailAndPassword().
You could use the new (as of Nov 2016) firebase-admin library (java or node) to programmatically create users from your server side - see this link for details.
After that, you could send the email and password to the user via email, and allow only email based password logins. Unfortunately, you can't force uninvited people to stop authenticating with your app, as they could manually invoke the APIs used to create a new account on their own, as you see on the same page. However, you are under no obligation to provide a login mechanism via your UI. They would have to use their browser to type and invoke the JS needed to create the account.
If you are OK with people forcibly creating accounts, but you would like to lock down their access, you could do something similar to what Frank mentions in another answer by using admin control of the database to restrict access to those users you have created and invited with a special flag in the database (that only you can modify using the admin SDK) that acts as a gateway into your app. If you perform the security properly, that should prevent those whom you didn't invite from using the app, even if they can effectively authenticate with it.
There are quite a few examples and tutorials on authentication and node out there, as well as several questions on stackoverflow. I'm still struggeling with this subject however when trying to implement authentication for an API which communicates with a SPA. I tried using mean.js as an example as well as to use JWT and passport.js. But even after some days of research and trial and error it is still unclear to me how to achieve the following scenario:
A user registers himself with a username (or email) and a password (and gets an email to verify his account)
The user logs himself in with the password and username.
The user recieves a token as a response
The token is used in all following requests which require authentication (and is invalidated after a given amount of time).
If the user logs out, the token is invalidated and he gets a new one the next time he logs in.
At a later point of time I also would like to implement Facebook and Google Login (that's why I would like to use passport.js).
I'm glad for any help and also open to suggestions for a better authentication flow.
Looking into Firebase (https://www.firebase.com/). It simplifies the process of handling Auth and all the perils of trying to handle Auth yourself.
Firebase also supports all of the major Auth providers out of the box (Facebook, Google, Twitter, etc).
I ended up using the node-example of satellizer:
https://github.com/sahat/satellizer/blob/master/examples/server/node/server.js#L36
You store password and username to the database on signup.
For logging in one can you simply compare the (hashed) password with the proved one and send back a token you create via jwt.encode (jsonwebtoken).
After that you append the token to your requests (in the header is probably the best way) and check its validity via jwt.decode(token, TOKEN_SECRET)
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.
I'm building an application using AngularFire + Firebase.
To prevent new users from being created, and authenticated, from domains other than my application's domain, I'm trying to use the Authorized Request Origins feature in Firebase.
Currently, it is only configured to allow authentication from localhost. However, when I create a new user using the createUser API from my application's domain, the user gets created in my Firebase.
This should not happen since I used "err" from createUser is null.
Is there anything else I need to configure?
[Engineer at Firebase] The authorized request origins is actually only applicable to the OAuth-based authentication providers (i.e. Facebook, Twitter, and GitHub) though your confusion is definitely warranted given our current interface. E-mail and password authentication is not subject to the same origin verification because it is not vulnerable to a malicious site taking advantage of an existing login on Facebook, Twitter, etc.
Keep it mind that email / password authentication only creates a mapping of an email address to a password hash, and generates a corresponding Firebase authentication token upon login. It does not read or write any data to / from your Firebase, and your Firebase is still subject to the same security rules that you've written for your application. Feel free to reach out to support#firebase.com if you have other concerns, or we can help out in any way.