node-express-boilerplate Add support for Google auth

Allow authentication with Google sign-in. This includes registering the user (on first login) and integrating with the current access token setup.

Feb 16 '20 21:02 hagopj13

Issue taken?

Dec 13 '20 19:12 Beardless-sheik

Hi @Beardless-sheik, the issue is not taken yet. You can do a PR.

Dec 14 '20 12:12 hagopj13

I'm very interested in this one, since I'm trying to make Google sign in without redirection, so my FE makes the work and sends token to BE. @Beardless-sheik how do you plan to validate Google's token before using to to create internal token? Any ideas would be appreciated :)

Dec 14 '20 17:12 codenomnom

@codenomnom the issue is still up for grabs if you would like to do a pull request.

Dec 18 '20 10:12 hagopj13

Hey, thanks. I can surely try to come up with some solution. But first - what are your thoughts on the way this should work? I can think of two ways to do so - 1) use passport google strategy, or 2) use passport http bearer.

The first one is super opinionated and requires get endpoint that redirects to google sign in (through passport.authenticate), then comes back and registers the user. This means it either need to make a full front-end page redirection, or in case of opening a popup - backend needs to render "close me" javascript in order for it to close 😃

The second approach is more API oriented, waiting for the front-end to provide access token, register the user and return another "system token" as you've already setup in tokens service (that would be later on used for authorizing routes). But here comes the question - how do we validate the access token?

There might be some other approach - I'd be happy if you share any ideas 😃 For my current project I've used the first approach: FE opens new popup, pointing to backend (auth/google). Route calls passport.authenticate('google'), which redirects to Google sign in. Callback url is again backend route (auth/google/callback). It registers/logs-in the user, and then it renders a js script. The popup itself sends a message to it's opener (the main web page) with the user profile, and then the popup closes itself using window.close() (a bit more complicated, but does the same).

Dec 18 '20 11:12 codenomnom

@hagopj13 any news on this one?

Dec 23 '20 15:12 codenomnom

Hi @codenomnom, sorry for the late reply. Thanks for your input. I prefer to go with the second (API-oriented) approach that you mentioned. What I can already picture is something like this: User logs in via google on UI, after which an access token is sent to the google login route of the server. The server uses that access token to fetch information about the user from Google and creates an account if not found (with a random password). The server then returns a refresh token and an access token (just like the regular login) back to the user. The user can keep on using that same refresh token to actually get a new access token every time, until the refresh token expires, after which the user has to login via Google again (of course a new user account will not be created now). Some notes:

To decide whether a user already exists or not could be easily done through the email found in the info fetched from Google
The User model can also be extended to include the user's 'Google ID' which is also found in the info fetched from Google. This could potentially also be done in a modular way services: { google: 'some-google-id' } so that in the future more services can be integrated.

Please let me know what you think.

Dec 24 '20 16:12 hagopj13

Why not, but you should think about something instead of a random password.