Assuming that you are doing the following:
- Signing in from the Web
- Using JavaScript for Sign-in and all data access
The following measures preventing malicious 3Ps from making API calls using your credentials / other user credentials:
- API calls are domain-restricted to the authorized origins you configured in the developer console
- API calls are restricted to the current credentials (e.g. only can get current user details / can only get credentials and tokens for the current user)
That said, let's move on to authN: making sure the user is who they claim to be. On the sign-in callback, you will receive a special token, the ID token, that has:
- The audience for the token (your client ID)
- The issuer of the token (user ID from profile)
- An issued timestamp
- An expiration timestamp
- etc..
These values are used to prevent forgery and avoid the confused deputy problem. For example, you use these values to check claims of who the user is, that the issuer of the token was you, and that the token has not expired. You also look at the ID token signature and validate it either using JWT functionality or by passing it to the Google verify token endpoint.
After verifying the user using the ID token, you can set a cookie for establishing a session and avoid having to verify the user on every API call.
Google provides token verification samples here, for example, the Google+ Token Verification sample in Ruby. Additionally, the Google+ quickstart samples demonstrate establishing a client-server session in the "/connect" server endpoints on the server-side languages (Ruby, Python, .NET, etc).
Additional discussion on the topic is available in the Identity Cookbook.
