I'm using Google Sign In to authenticate my users with my server back end via my Android app.

So far I am able to sign in and obtain an ID token, which I then send to my server back end for verification, which I can do using the PHP Google API Client library. After this point, the Google documentation says:

Create an account or session

After you have verified the token, check if the user is already in your user database. If so, establish an authenticated session for the user. If the user isn't yet in your user database, create a new user record from the information in the ID token payload, and establish a session for the user. You can prompt the user for any additional profile information you require when you detect a newly created user in your app.

Q: What are the benefits of establishing an authenticated session for the user? Can't I just use the token ID each time to identify the user in my server end point? Surely if the ID token has expired, I can just tell the client and have the client silently sign in to Google again, then use the new ID token to access my end point successfully.

If I did go on to use my own JWT tokens after the Google Sign In, all I'd really be doing is swapping one JWT for another, except that I would have control over the contents of my own JWT's, e.g. validity time.

Note: the Google token ID contains a "sub" number which uniquely identifies the user, so I can easily use that to index into my database.

  • How would store the information which token IDs belong to the same user? – Josef May 14 '18 at 13:50
  • @Josef The token ID contains a "sub" number which uniquely identifies the user. It would be easy to use that, no problem. The sub field never changes. – Pixel May 14 '18 at 13:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.