Google Login Tutorial - Part 5

In previous part of Google Login Tutorial we have discussed step 4 Authenticating User. Now in this part we are going to discuss step 5 and step 6. Note that this is the last part of tutorial.

Step 5 : Obtaining user information from ID Token:

An ID Token is a JWT (JSON Web Token), that is, a cryptographically signed Base64-encoded JSON object. Normally, it is critical that you validate an ID token before you use it, but since we are communicating directly with Google over an intermediary-free HTTPS channel and using your client secret to authenticate yourself to Google, we can be confident that the token you receive really comes from Google and is valid. If our server passes the ID token to other components of your app, it is extremely important that the other components validate the token before using it.

An ID token’s payload : An ID token is a JSON object containing a set of name/value pairs. Here’s an example, formatted for readability:

{"iss":"accounts.google.com","at_hash":"HK6E_P6Dh8Y93mRNtsDB1Q","email_verified":"true","sub":"10769150350006150715113082367","azp":"1234987819200.apps.googleusercontent.com","email":"jsmith@example.com","aud":"1234987819200.apps.googleusercontent.com","iat":1353601026,"exp":1353604926,"hd":"example.com" }

 

Google ID Tokens may contain the following fields (Also known as claims):

• iss : The Issuer Identifier for the Issuer of the response. Always accounts.google.com or https://accounts.google.com for Google ID tokens.
• at_hash : Access token hash. Provides validation that the access token is tied to the identity token. If the ID token is issued with an access token in the server flow, this is always included. This can be used as an alternate mechanism to protect against cross-site request forgery attacks.
• email_verified : True if the user’s e-mail address has been verified; otherwise false.
• sub : An identifier for the user, unique among all Google accounts and never reused. A Google account can have multiple emails at different points in time, but the sub value is never changed. Use sub within your application as the unique-identifier key for the user.
• azp : The client_id of the authorized presenter. This claim is only needed when the party requesting the ID token is not the same as the audience of the ID token. This may be the case at Google for hybrid apps where a web application and Android app have a different client_id but share the same project.
• email : The user’s email address. This may not be unique and is not suitable for use as a primary key. Provided only if your scope included the string “email”.
• aud : Identifies the audience that this ID token is intended for. It must be one of the OAuth 2.0 client IDs of your application.
• iat : The time the ID token was issued, represented in Unix time (integer seconds).
• exp : The time the ID token expires, represented in Unix time (integer seconds).
• hd : The hosted Google Apps domain of the user. Provided only if the user belongs to a hosted domain.

Step 6: Authenticate the user

The last and final step is Authenticating user. After obtaining user information from the ID token, we can query our app’s user database. If the user already exists in our apps database, our app should start an application session for that user.

If the user does not exist in our user database, our app should redirect the user to your new-user sign-up flow. We may be able to auto-register the user based on the information we have receive from Google, or at the very least we are also able to pre-populate many of the fields that you require on your registration form. In addition to the information in the ID token, we can also get additional user profile information at our user profile endpoints.