I have successfully implemented Google Login in my web application, using OAuth 2.0 for Client-side Web Applications. For most needs, I just need to have the user log into my application once, and I pass the id_token back to my server to authenticate it, and give back a JWT token to the front end on success. The user doesn't have to log every time they visit the page by storing that JWT token in the browser.
Now I want to build some additional capabilities into my application that require me to act on behalf of the user, and so I have to incrementally ask for additional scopes. I think I have a handle on that aspect.
On the client side, I gain consent to use a Google API on behalf of a user, and then use the Bearer token I get back to make a request to that API, then I get back an object from Google.
Now I want to convey that object to my server (my back-end) to store some information in my database associated with the user that is logged into my system. How do I authenticate, on my server, that the object I got back from Google, by proxy through the browser, actually belongs to the user who is conveying it to my server.
What's to stop someone from using cURL with their valid JWT token to my server and conveying some arbitrarily constructed Google object of their own creation. I don't see anything in the Google response object that I can verify its authenticity on my server (like I can with the id_token I get from their successful login, as described here). Perhaps there is a 'sub' field (which I think is Google's notion of identity) on the object which at least lets me know it belongs to the Google User, if I can trust the object's authenticity in the first place.
Can anyone set me straight and give me a reasonably intuitive mental model to organize my thoughts around, and tell me if I'm way off base with my concerns here, or if I'm approaching this from an entirely wrong vantage point?
