nodejs, passport, google and an API - node.js

How do you authentication multiple websites through a single NodeJS API using passport's google authentication strategy?
The API is hosted separately to the webpages. From playing with the guides on the passport website and tutorials I can find, they all rely on the Node application doing the page rendering (i.e. using Jade etc) and not passing a token back to a separate web application
What is the best approach for creating a single API that can authenticate against Google and return a token to the client without having the API and the website(s) hosted on the same box and all served by NodeJS?
I can get the strategy to work when accessing the API endpoints directly, but I cannot figure out how an application would interact with those, and get a token back when they are on different domains.

Related

What's the best way to authenticate and authorize a web and api solution like MERN Stack?

I'm trying to find the best way to implement authorization. At this time, only thing I need is a simple free account, but later I may include user roles for a "premium" account using a payment system like stripe.
I have already started reading and experimenting with Auth0 but then found some other ways I can do it.
Passport.js + MongoDB, I've seen some examples and work great but I think it is missing a way to control users, rules etc with a friendly panel (like Auth0)
Using Auth0 and setting up a custom database (mongoDB). Also seems to be behind a paywall.
Also found a way to use both Auth0 for authentication and Mongoose for a MongoDB database. In this one, everything is saved in mongoDB except passwords. It's also the only setup that deleting a user from Auth0 is not affecting the MongoDB (which is bad I guess).
So, some questions are
which method you think is better?
What is the difference between 2 and 3,
Is there a way to implement rules in passport (e.g. redirect new users on first login)
If I implement Passport with MongoDB, and my database has hundreds of users, how can I manage them?
A bit of a chaos question but any help would be helpful
The best authorization strategy depends of the scope of your applications in a short or long term.
Monolithic or simple web with Private login
For example, if you will have just a simple(MERN) web with a one simple backend (api rest) or a monolithic application like this mern example with an internal or private login in your organization, your authorization strategy could be as simple as :
(1*) /login express route which receive user/password, validate them in database and returns the clasic jwt token and an array of options (react routes) to which the user should have access
web app (react) must render pages whose routes match with the received routes
web app must send the received token to any api rest endpoint invocation
when api receive the invocation from react web, must validate the existence of token as a header. If not exist, must return a 403 error.
(2*) If token exist, must try to validate it (well-formed, not expired, correct signature, etc).
(3*)If its is a valid token, you must perform a last validation: Is user with "guest" role allowed to execute a DELETE to an endpoint /user/100.
(4*) Classic solution is to have some tables in your database like: user, roles, user_roles, role_permission, permission_option. Option table must have registered all your api endpoints and its method. Also this could be used to create the relation between user <:> web routes. Check this
Modern requirements
Modern and large organizations require:
Social Network Logins
Internal/External Users
Not interactive logins (robots, schedulers, etc)
Several web apps
Several Mobile apps
A lot of Api Rest
For this case, MERN app is not a good choice because is ALL-IN-ONE. Common strategy to implement the previous requirements is to have several artifacts deployed in several servers:
web app (react, vue, angular, linkstart, etc)
apis rest (nodejs + expres, java, python, etc)
authentication/authorization: oauth2 platform/provider, Identity/Access Platforms, etc
If this is your case, you must split your MERN app into several deployable artifacts: web, api and security.
Oauth2
No matter if you are concern just for login or how ensure the authentication and authorization for your webs, apis and maybe your mobile apps, you will need : OAUTH2
You could develop your own security platform taking into consideration (1*), (2*), (3*) y (4*) or use something like:
auth0
keycloack, etc
More details here: https://stackoverflow.com/a/62049409
Your questions
which method you think is better?
I think if you will use auth0, you will save time and effort. With auth0 you just need a simple express app, with some endpoints like /login, /callback, etc. Or if you use auth0 + passport.js, these endpoints are managed by passport.js
I advice you , review how OAUTH2 flow works before to use auth0 with/without passport. This link helped me a lot.
What is the difference between 2 and 3,
As I read, auth0 and another platforms offer a user management service or it can connect to your users service (AD/LDAP, database, api, etc). So
Is there a way to implement rules in passport (e.g. redirect new users on first login)
Yes. You can add some logic when callback is redirected in your nodejs with or without passport.
If I implement Passport with MongoDB, and my database has hundreds of users, how can I manage them?
Nowadays database support a lot of rows. So for your production database try to optimize or monitor it. Another option is to hire a database administrator to perform these tasks.
References
https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2
https://auth0.com/user-management
https://stackoverflow.com/a/62049409
https://fiware-tutorials.readthedocs.io/en/latest/roles-permissions/index.html
https://dba.stackexchange.com/questions/36935/best-relational-database-structure-for-this-data
https://www.mind-it.info/2010/01/09/nist-rbac-data-model/
Managing single sign on using passportjs for my own web applications - sharing login
https://aws.amazon.com/blogs/apn/how-to-integrate-rest-apis-with-single-page-apps-and-secure-them-using-auth0-part-1/
Facebook OAuth security using passport-facebook
Asynchronous Django, Ajax, Jquery Information
relational models

Adding google authentication to a Node REST API

I want to create a backend API where I should be able to allow users to log in through Google/Linkedin/Email. I need to create this as an API and not a server-rendered app. I can make email using jsonwebtoken package in NodeJs or use passportJS. But how can I enable Google login/LinkedIn login and protected routes in ExpressJS with all three authentication methods?
How can I do it? I am not able to find a good resource with a Node REST API.

What is the difference between passport-google-oauth and passport-google-token?

I am trying to validate my node app using google. But I found these two modules being used in different tutorials. Could you please tell what the difference is between these two.
passport-google-token
On the npmjs.com page of both, i found the desc as Passport strategy
for authenticating with Google access tokens using the OAuth 2.0 API.
This module lets you authenticate using Google in your Node.js
applications. By plugging into Passport, Google authentication can be
easily and unobtrusively integrated into any application or framework
that supports Connect-style middleware, including Express.
passport-google-oauth
Passport strategies for authenticating with Google using OAuth 2.0.
Lead Maintainer: David Pate
This module lets you authenticate using Google in your Node.js
applications. By plugging into Passport, Google authentication can be
easily and unobtrusively integrated into any application or framework
that supports Connect-style middleware, including Express.
passport-google-oauth was made for express apps, so you can configure permissions, callback uri and request user data, all in the same place.
passport-google-token is made for REST APIs, so you handle authentication logic in front-end and then, you send google token to the back-end (node server) and there you can request user data using google token and grant access to your app using your own authentication mechanism (JWT, Bearer Token, etc.).

How to protect a NodeJS API server used with a React application?

I have a React front-end that calls REST APIs. The front-end and back-end are hosted on different servers. It's a simple application so I don't want to implement User accounts/API keys. How do I secure the backend so that it could be only used by my React front-end.
you cannot, the only way that I see could come close is by generating a token that's embedded in one of your static React files and validate that token upon request (for every instance downloaded by a user), but it would be impossible to prevent an attacker from fetching that file/token and call the backend APIs with it. The only way to protect a backend is via user login/2-legged OAuth.

User/Pass Authentication API on NodeJS without Express

I am currently developing an API project using ClaudiaJS API Builder to build and deploy it on AWS Lambda with it's endpoints exposed on AWS API Gateway. I am planning to have at least a webapp and a mobile app for this platform, so I'm focusing mostly everything on API's, including the authentication methods(signup, signin, logout, verify account, ect.).
Unfortunately, as I am not using Express in this project, I can't find a good way to build these auth methods since every library I find has some dependency on Express (e.g PassportJS).
My initial thoughts for the login workflow are:
User submits login form containing user/pass stored in PostgreSQL
DB.
Front app calls auth API.
API method compared credentials against the user DB (Using BCrypt).
In case of success, API method generates JWT containing a few user details on it's payload and returns to the consumer app.
Is there any good approach for achieving this goal without using Passport and/or Express? Are there any other libs for this purpose or should I just use a regular db query and generate a JWT in case the evaluation succeeds?
Thanks for everyone in advance.
Best regards,
Enrico Bergamo

Resources