La dissociation peut être lancée depuis votre plate-forme ou Google. L'affichage d'un état de liaison cohérent sur les deux offre la meilleure expérience utilisateur possible. La compatibilité avec un point de terminaison de révocation de jeton ou la protection multicompte est facultative pour l'association de comptes Google.
Les comptes peuvent être dissociés pour les raisons suivantes:
- Demande de l'utilisateur de
- une application Google ou les paramètres de votre compte Google
- Votre plate-forme
- Échec du renouvellement d'un jeton d'actualisation expiré
- Autres événements déclenchés par vous ou par Google Par exemple, la suspension de compte par des services de détection des abus et des menaces.
L'utilisateur a demandé à dissocier son compte de Google
La dissociation de compte lancé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 appelle éventuellement votre point de terminaison de révocation de jeton si vous avez choisi d'en implémenter un.
L'utilisateur a demandé à être dissocié de votre plate-forme
Vous devez fournir un mécanisme permettant aux utilisateurs de dissocier leur compte, par exemple une URL vers leur compte. Si vous ne proposez pas aux utilisateurs un moyen de dissocier leur compte, incluez un lien vers le compte Google afin qu'ils puissent le gérer.
Vous pouvez choisir d'implémenter la gestion des risques et des incidents et la collaboration (RISC, Risk &Incident Sharing) et informer Google de modifications apportées à l'état d'association des comptes utilisateur. Cela permet d'améliorer l'expérience utilisateur, car votre plate-forme et Google affichent un état d'association actuel et cohérent sans avoir à s'appuyer sur une demande de rafraîchissement ou de jeton d'accès pour mettre à jour l'état de l'association.
Expiration des jetons
Pour offrir une expérience utilisateur fluide et éviter toute interruption de service, Google tente de renouveler les jetons d'actualisation peu avant la fin de leur durée de vie. Dans certains scénarios, le consentement de l'utilisateur peut être requis pour associer de nouveau les comptes lorsqu'un jeton d'actualisation valide n'est pas disponible.
En concevant votre plate-forme pour qu'elle accepte plusieurs jetons d'accès et d'actualisation non expirés, vous pouvez réduire les conditions de concurrence présentes dans les échanges client-serveur entre les environnements en cluster, éviter les interruptions pour les utilisateurs et réduire les scénarios complexes de gestion des codes temporels et de gestion des erreurs. Bien que finalement cohérents, les jetons non expirés précédemment émis et nouvellement émis peuvent être utilisés pendant une courte période lors de l'échange de renouvellement de jeton client-serveur et avant la synchronisation du cluster. Par exemple, une requête Google envoyée à votre service qui utilise le jeton d'accès précédent non expiré se produit juste après l'émission d'un nouveau jeton d'accès, mais avant la réception et la synchronisation du cluster chez Google. D'autres mesures de sécurité que la rotation des jetons d'actualisation sont recommandées.
Autres événements
Les comptes peuvent être dissociés pour diverses autres raisons, telles que l'inactivité, la suspension, un comportement malveillant, etc. Dans ce cas, votre plate-forme et Google peuvent mieux gérer les comptes utilisateur et les réassocier en s'informant mutuellement des modifications apportées à l'état du compte et de l'association.
Implémentez un point de terminaison de révocation de jeton que Google peut appeler, et informez Google de vos événements de révocation de jeton à l'aide de RISC pour vous assurer que votre plate-forme et Google maintiennent un état d'association de compte utilisateur cohérent.
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) :