Unlinking may be initiated from your platform or Google, and the display of a consistent link state on both provides the best user experience. Support for a token revocation endpoint or Cross-Account Protection is optional for Google Account Linking.
Accounts can become unlinked by any of the following:
- User request from
- a Google application or Google Account settings
- Your platform
- Failure to renew an expired refresh token
- Other events initiated by you or Google. For example, account suspension by abuse and threat detection services.
User requested unlinking from Google
Account unlinking initiated through a user's Google Account or app deletes any previously issued access and refresh tokens, removes user consent, and optionally calls your token revocation endpoint if you chose to implement one.
User requested unlinking from your platform
You should provide a mechanism for users to unlink, such as a URL to their account. If you don't offer a way for users to unlink, include a link to the Google Account so that the users can manage their linked account.
You can choose to implement Risk & Incident Sharing and Collaboration (RISC) and notify Google of changes to the users account linking status. This allows for an improved user experience where both your platform and Google show a current and consistent linking status without the need to rely on a refresh or access token request to update linking state.
To provide a smooth user experience and avoid service disruption, Google attempts to renew refresh tokens near the end of their lifetime. In some scenarios, user consent might be required to re-link accounts when a valid refresh token is unavailable.
Designing your platform to support multiple unexpired access and refresh tokens can minimize race conditions present in client-server exchanges between clustered environments, avoid user disruption, and minimize complex timing and error handling scenarios. While eventually consistent, both previous and newly issued unexpired tokens might be in use for a short period of time during the client-server token renewal exchange and prior to cluster synchronization. For example, a Google request to your service that uses the previous unexpired access token occurs just after you issue a new access token, but before receipt and cluster synchronization takes place at Google. Alternative security measures to Refresh Token Rotation are recommended.
Accounts can be unlinked due to various other reasons, such as inactivity, suspension, malicious behavior, and so forth. In such scenarios, your platform and Google can best manage user accounts and relink by notifying one another of changes to account and link state.
Implement a token revocation endpoint for Google to call, and notify Google of your token revocation events using RISC to ensure your platform and Google maintain consistent user account link state.
Token revocation endpoint
If you support an OAuth 2.0 token revocation endpoint, your platform can receive notifications from Google. This lets you inform users of link state changes, invalidate a token, and cleanup security credentials and authorization grants.
The request has the following form:
POST /revoke HTTP/1.1 Host: oauth2.example.com Content-Type: application/x-www-form-urlencoded client_id=GOOGLE_CLIENT_ID&client_secret=GOOGLE_CLIENT_SECRET&token=TOKEN&token_type_hint=refresh_token
Your token revocation endpoint must be able to handle the following parameters:
|Revocation endpoint parameters
|A string that identifies the request origin as Google. This string must be registered within your system as Google's unique identifier.
|A secret string that you registered with Google for your service.
|The token to be revoked.
|(Optional) The type of token being revoked, either an
refresh_token. If unspecified,
Return a response when the token is deleted or invalid. See the following for an example:
HTTP/1.1 200 Success Content-Type: application/json;charset=UTF-8
If the token can't be deleted for any reason, return a 503 response code, as shown in the following example:
HTTP/1.1 503 Service Unavailable Content-Type: application/json;charset=UTF-8 Retry-After: HTTP-date / delay-seconds
Google retries the request later or as requested by
Cross-Account Protection (RISC)
If you support Cross-Account Protection, your platform can notify Google when access or refresh tokens are revoked. This allows Google to inform users of link state changes, invalidate the token, cleanup security credentials, and authorization grants.
Cross-Account Protection is based on the RISC standard developed at the OpenID Foundation.
A Security Event Token is used to notify Google of token revocation.
When decoded, a token revocation event looks like the following example:
"token": "double SHA-512 hash value of token"
Security Event Tokens that you use to notify Google of token revocation events must conform to the requirements in the following table:
|Token revocation events
|Issuer Claim: This is a URL which you host, and it's shared with Google during registration.
|Audience Claim: This identifies Google as the JWT recipient. It
must be set to
|JWT ID Claim: This is a unique ID that you generate for every security event token.
|Issued At Claim: This is a
that represents the time when this security event token was created.
|Time of Event Claim: This is an optional
NumericDate value that represents the time at which the
token was revoked.
|Expiration Time Claim: Do not include this field, as the event resulting in this notification has already taken place.
For more information on field types and formats, see JSON Web Token (JWT).