After Google returns an ID token, it's submitted by an HTTP
request, with the parameter name
credential, to your login endpoint.
The following is an example in the Python language that shows the usual steps to validate and consume the ID token:
Verify the Cross-Site Request Forgery (CSRF) token. When you submit credentials to your login endpoint, we use the double-submit-cookie pattern to prevent CSRF attacks. Before each submission, we generate a token. Then, the token is put into both the cookie and the post body, as shown in the following code example:
csrf_token_cookie = self.request.cookies.get('g_csrf_token') if not csrf_token_cookie: webapp2.abort(400, 'No CSRF token in Cookie.') csrf_token_body = self.request.get('g_csrf_token') if not csrf_token_body: webapp2.abort(400, 'No CSRF token in post body.') if csrf_token_cookie != csrf_token_body: webapp2.abort(400, 'Failed to verify double submit cookie.')
Verify the ID token. Refer to Verify the integrity of the ID token for details.
Based on the correlated account status for the email address in the ID token, you can redirect the user to different flows, as follows:
An unregistered email address: You can show a sign-up user interface (UI) that allows the user to provide additional profile information, if required. It also allows the user to silently create the new account and a logged-in user session.
A legacy account that exists for the email address: You can show a web page that allows the end user to input their password and link the legacy account with their Google credentials. This confirms that the user has access to the existing account.
A returning federated user: You can silently sign the user in.