La dissociation peut être lancée depuis votre plate-forme ou Google, et l'affichage d'un état de lien cohérent sur les deux fournit la meilleure expérience utilisateur. La compatibilité avec un point de terminaison de révocation de jetons ou la protection multicompte est facultative pour l'association de comptes Google.
Un compte peut être dissocié de l'une des façons suivantes:
- Demande utilisateur de
- Une application Google ou les paramètres du compte Google
- Votre plate-forme
- Échec du renouvellement d'un jeton d'actualisation expiré
- Autres événements initiés par vous-même ou par Google (par exemple, la suspension d'un compte par le biais d'un service de détection des utilisations abusives ou des menaces).
Un utilisateur a demandé la dissociation de son compte de Google
La dissociation de compte initiée via le compte Google ou l'application d'un utilisateur supprime tous les jetons d'accès et d'actualisation précédemment émis, supprime le consentement de l'utilisateur et, si vous le souhaitez, appelle votre point de terminaison de révocation de jetons.
Un utilisateur a demandé la dissociation de votre chaîne
Vous devez fournir à l'utilisateur un mécanisme de dissociation, tel qu'une URL vers son compte. Si vous ne proposez aucun moyen de dissocier les utilisateurs, incluez un lien vers le compte Google afin qu'ils puissent gérer leur compte associé.
Vous pouvez choisir d'implémenter le partage des risques et la collaboration (RISC, Incident Share and Collaboration) et d'informer Google des modifications apportées à l'état d'association du compte utilisateur. Cela permet d'améliorer l'expérience utilisateur, car votre plate-forme et Google affichent un état d'association cohérent et actuel sans avoir à s'appuyer sur une requête d'actualisation ou de jeton d'accès pour mettre à jour l'état d'association.
Expiration du jeton
Pour offrir une expérience utilisateur fluide et éviter toute interruption de service, Google tente de renouveler les jetons d'actualisation vers la fin de leur durée de vie. Dans certains scénarios, le consentement de l'utilisateur peut être requis pour réassocier les comptes lorsqu'un jeton d'actualisation valide n'est pas disponible.
En concevant votre plate-forme pour accepter plusieurs jetons d'accès et d'actualisation non expirés, vous pouvez minimiser les conditions de concurrence présentes dans les échanges client-serveur entre les environnements en cluster, éviter les perturbations de l'utilisateur, et minimiser les scénarios complexes et la gestion des erreurs. Bien qu'ils finissent par être cohérents, les jetons précédents et les nouveaux jetons non expirés peuvent être utilisés pendant une courte période au cours de l'échange de renouvellements de jetons entre le client et le serveur, et avant la synchronisation du cluster. Par exemple, une requête Google adressée à votre service qui utilise le jeton d'accès précédent non expiré intervient juste après l'émission d'un nouveau jeton d'accès, mais avant la synchronisation des reçus et des clusters. Des mesures de sécurité alternatives à la rotation des jetons d'actualisation sont recommandées.
Autres événements
Les comptes peuvent être dissociés pour diverses autres raisons, comme l'inactivité, la suspension, le comportement malveillant, etc. Dans de tels cas, votre plate-forme et Google peuvent mieux gérer les comptes utilisateur et effectuer une nouvelle association en s'informant mutuellement des modifications apportées à l'état du compte et de l'association.
Mettez en œuvre un point de terminaison de révocation de jetons pour que Google vous appelle, et informez Google de vos événements de révocation de jetons à l'aide de RISC pour vous assurer que la plate-forme et Google maintiennent l'état de l'association des comptes utilisateur.
Point de terminaison de révocation du jeton
Si vous prenez en charge un point de terminaison de révocation de jeton OAuth 2.0, votre plate-forme peut recevoir des notifications de Google. Cela vous permet d'informer les utilisateurs des changements d'état des liens, d'invalider un jeton et de nettoyer les informations d'identification de sécurité et les autorisations.
La demande a la forme suivante:
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
Votre point de terminaison de révocation de jeton doit être capable de gérer les paramètres suivants:
| Paramètres de point de terminaison de révocation | |
|---|---|
client_id | Une chaîne qui identifie l'origine de la demande en tant que Google. Cette chaîne doit être enregistrée dans votre système en tant qu'identifiant unique de Google. |
client_secret | Une chaîne secrète que vous avez enregistrée auprès de Google pour votre service. |
token | Le jeton à révoquer. |
token_type_hint | (Facultatif) Le type de jeton révoqué, soit un access_token ou refresh_token . Si non spécifié, la valeur par défaut est access_token . |
Renvoie une réponse lorsque le jeton est supprimé ou invalide. Voir ce qui suit pour un exemple:
HTTP/1.1 200 Success Content-Type: application/json;charset=UTF-8
Si le jeton ne peut pas être supprimé pour une raison quelconque, renvoyez un code de réponse 503, comme illustré dans l'exemple suivant:
HTTP/1.1 503 Service Unavailable Content-Type: application/json;charset=UTF-8 Retry-After: HTTP-date / delay-seconds
Google réessaye la demande plus tard ou comme demandé par Retry-After .
Protection multicompte (RISC)
Si vous acceptez la protection multicompte, votre plate-forme peut avertir Google lorsque les jetons d'accès ou d'actualisation sont révoqués. Cela permet à Google d'informer les utilisateurs des changements d'état des liens, d'invalider le jeton, de nettoyer les identifiants de sécurité et d'accorder les autorisations.
La protection multicompte est basée sur la norme RISC développée par l'OpenID Foundation.
Un jeton d'événement de sécurité permet d'informer Google de la révocation d'un jeton.
Lorsqu'il est décodé, un événement de révocation de jeton se présente comme suit:
{
"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"
}
}
}
Les jetons d'événement de sécurité que vous utilisez pour informer Google des événements de révocation de jeton doivent respecter les exigences décrites dans le tableau suivant:
| Événements de révocation de jetons | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
iss |
Revendication de l'émetteur:il s'agit d'une URL que vous hébergez, et qui est partagée avec Google lors de l'enregistrement. | ||||||||||
aud |
Revendication de l'audience:Google est le destinataire du jeton JWT. Il doit être défini sur google_account_linking. |
||||||||||
jti |
Revendication d'ID JWT:il s'agit d'un ID unique que vous générez pour chaque jeton d'événement lié à la sécurité. | ||||||||||
iat |
Issued At Claim (Émise lors de la revendication) : il s'agit d'une valeur NumericDate qui représente l'heure à laquelle ce jeton d'événement de sécurité a été créé. |
||||||||||
toe |
Heure de la revendication de l'événement:il s'agit d'une valeur NumericDate facultative qui représente l'heure à laquelle le jeton a été révoqué. |
||||||||||
exp |
Expiration Time Claim (Revendication de l'heure d'expiration) : n'incluez pas ce champ, car l'événement à l'origine de cette notification a déjà eu lieu. | ||||||||||
events |
|
||||||||||
Pour en savoir plus sur les types et les formats de champs, consultez la page Jeton Web JSON (JWT).