Unlinking accounts

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.

Token expiration

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.

Other events

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

如果您支持OAuth 2.0令牌吊销终结点，则您的平台可以接收来自Google的通知。这使您可以通知用户链接状态更改，使令牌无效以及清理安全凭证和授权授予。

该请求具有以下形式：

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

您的令牌吊销终结点必须能够处理以下参数：

撤销端点参数
`client_id`	一个字符串，用于将请求来源标识为Google。此字符串必须在您的系统中注册为Google的唯一标识符。
`client_secret`	您在Google注册的用于服务的秘密字符串。
`token`	要撤消的令牌。
`token_type_hint`	（可选）要撤消的令牌类型，可以是`access_token`或`refresh_token` 。如果未指定，则默认为`access_token` 。

当令牌被删除或无效时返回响应。请参见以下示例：

HTTP/1.1 200 Success
Content-Type: application/json;charset=UTF-8

如果由于某种原因无法删除令牌，请返回503响应代码，如以下示例所示：

HTTP/1.1 503 Service Unavailable
Content-Type: application/json;charset=UTF-8
Retry-After: HTTP-date / delay-seconds

Google稍后或按照Retry-After的要求重试该请求。

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:

{
  "iss":"http://risc.example.com",
  "iat":1521068887,
  "aud":"google_account_linking",
  "jti":"101942095",
  "toe": "1508184602",
  "events": {
    "https://schemas.openid.net/secevent/oauth/event-type/token-revoked":{
      "subject_type": "oauth_token",
      "token_type": "refresh_token",
      "token_identifier_alg": "hash_SHA512_double",
      "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

iss Issuer Claim: This is a URL which you host, and it's shared with Google during registration.

aud Audience Claim: This identifies Google as the JWT recipient. It must be set to google_account_linking.

jti JWT ID Claim: This is a unique ID that you generate for every security event token.

iat Issued At Claim: This is a NumericDate value that represents the time when this security event token was created.

toe Time of Event Claim: This is an optional NumericDate value that represents the time at which the token was revoked.

exp Expiration Time Claim: Do not include this field, as the event resulting in this notification has already taken place.

events

Security Events Claim: This is a JSON object, and must include only a single token revocation event.
`subject_type`	This must be set to `oauth_token`.
`token_type`	This is the type of token being revoked, either `access_token` or `refresh_token`.
`token_identifier_alg`	This is the algorithm used to encode the token, and it must be `hash_SHA512_double`.
`token`	This is the ID of the revoked token.

For more information on field types and formats, see JSON Web Token (JWT).