Wednesday, November 25, 2015

Anatomy of an application that uses Google OAUTH2

Ever wondered how the login to Google and Facebook buttons work on many web-applications? In a nutshell, these web-applications rely on Google/Facebook to handle the user identification piece and then Google/Facebook shares some information about the user with the web-application. This relieves the web-application from having to devise a login mechanism and store passwords, and also relieves the user from having to remember multiple usernames and passwords. So, WIN-WIN.

Suppose you are setting up a web-application that would like to use google's login. Your web-app runs at http://www.example.com/tracker (or http://localhost:3000/) . So, how do you integrate with Google's login?

Turns out, it can be done in 4 steps:

1. register your application with Google. After all, Google needs to know who is using it's login service. This step creates a client-id (which is used to identify your application) and a client-secret (something that is used by your application in communicating with Google).

2. The user gets a code from Google. This is done by clicking a button or link on your web application that makes a request to Google. This request has your client-id and an endpoint that should be called after successful login. The endpoint is something like http://localhost:3000/google_auth, and will be called after successful login.

3. The web-application exchanges the  code for an authorization token. The authorization token is recognized by Google services. The web-application's client-secret is used to verify that it is your application which is involved in this transaction.

4. The authorization token is used to query the Google's Oauth2 webservice to get the user profile.

Registration

In order to use Google's services, you need to register your application. This involves creating a project in Google Developer Console and setting up credentials for the application(project). At the end of this step, you will have a client-id (a public id that is used to identify your application), a client-secret (which is known only to your application and is used to exchange code for tokens), and a set of well known endpoints in your application that google knows it's OK to redirect users back to after successful authentication.

Steps 2..4

A sequence of what needs to happen in steps 2..4 to get the user's identity is as follows.






No comments:

Post a Comment