What are the security benefits of creating a session vs. just using Google ID token every time in my server back end?

Question

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.

Answer 1

I had the same question about this paragraph in the docs, since everything was working fine with my app using the Google ID token to call my backend. I later learned:

First, consider this article about ID tokens vs. access tokens. In general, the best practice is for ID tokens to be used to establish identity, but then to acquire and use scope-based access tokens to access resources or perform actions.

I found that I was forced to adopt this pattern when implementing against other social login (in my case, Apple). In the case of Apple sign in, even though it also provided an ID token during initial login like Google, once that token expired, the Apple client provided no way to acquire a new ID token without making the user login again, negatively impacting the user experience. Apple docs also recommend creating your own session (token) to connect to your backend, which is basically required because otherwise the user would have to sign in every day. (In the Apple case, it's a bit more complicated because they also issue an auth code which needs to be exchanged for a refresh token, and then continuously verified.)

But another benefit of generating your own access token is that all of the backend endpoints (except for the ones for generating tokens) only need to understand tokens that you generate -- i.e., the tokens have the same issuer. In my case, this is really helpful, since I'm using AWS API Gateway HTTP, where it's much easier to verify tokens when they all have the same issuer.