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 acceptez l'authentification OAuth 2.0 point de terminaison de révocation du jeton. votre plate-forme peut recevoir des notifications de Google. Vous pouvez ainsi informer les utilisateurs de changement d'état d'un lien, invalider un jeton et nettoyer les informations d'identification et de sécurité les autorisations accordées.
La requête se présente sous 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 pouvoir gérer les paramètres suivants:
| Paramètres de point de terminaison de révocation | |
|---|---|
client_id |
Chaîne identifiant Google à l'origine de la requête. Cette chaîne ne doit doit être enregistré dans votre système en tant qu'identifiant unique de Google. |
client_secret |
Chaîne secrète que vous avez enregistrée auprès de Google pour votre service. |
token |
Jeton à révoquer. |
token_type_hint |
(Facultatif) Type de jeton révoqué :
access_token ou refresh_token. Si cette valeur n'est pas spécifiée, elle prend la valeur par défaut de access_token. |
Renvoyez une réponse lorsque le jeton est supprimé ou non valide. Pour en savoir plus, consultez l'exemple suivant :
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 relance la requête ultérieurement ou à la demande de Retry-After.
Protection multicompte (RISC)
Si vous proposez 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 les changements d'état du lien, invalider le jeton, nettoyer les identifiants de sécurité et les autorisations accordées.
La protection multicompte est basée sur le norme RISC développée à la OpenID Foundation.
Un jeton d'événement de sécurité est utilisé pour informer Google de la révocation du jeton.
Une fois 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"
}
}
}
Jetons d'événements de sécurité que vous utilisez pour informer Google des événements de révocation de jetons doivent respecter les exigences indiquées dans le tableau suivant:
| Événements de révocation de jetons | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
iss |
Déclaration de l'émetteur:il s'agit d'une URL que vous hébergez et qui est partagée avec Google lors de l'inscription. | ||||||||||
aud |
Revendication d'audience:cette option identifie Google comme le destinataire du jeton JWT. Il
doit être défini sur google_account_linking. |
||||||||||
jti |
Revendication d'ID JWT:il s'agit d'un identifiant unique que vous générez pour chaque et le jeton d'événement de sécurité. | ||||||||||
iat |
Émis au moment de la revendication:il s'agit d'une valeur de NumericDate
qui représente l'heure à laquelle ce jeton
d'événement de sécurité a été créé. |
||||||||||
toe |
Date et heure de la revendication de l'événement:cette information est facultative.
Valeur NumericDate représentant l'heure à laquelle
Le jeton a été révoqué. |
||||||||||
exp |
Revendication d'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 Jeton Web JSON (JWT) :