Pack de sécurité

Ce guide décrit un ensemble de fonctionnalités qui renvoient des signaux de confiance supplémentaires concernant un compte Google. Ces signaux de confiance aident votre système de gestion de compte à prendre des décisions basées sur les risques lors de la connexion, de la création de compte et plus tard pour les utilisateurs connus.

Sessions

Une requête d'authentification envoyée par une application renvoie un jeton d'identité. Par exemple, lorsqu'un bouton "Se connecter avec Google" est enfoncé, un jeton d'identité est renvoyé à l'application cliente ou serveur Android, iOS ou Web qui affiche le bouton.

L'authentification pour se connecter à un compte Google est un événement distinct. Les revendications renvoyées dans le jeton d'identité représentent cet événement. Par exemple, l'heure et les méthodes d'authentification utilisées pour se connecter au compte Google.

Il existe deux moments d'authentification et deux sessions utilisateur :

• Session utilisateur <-> Google : établie lorsqu'un utilisateur se connecte à son compte Google. Google gère le cycle de vie et la sécurité de cette session. Les revendications auth_time et amr vous fournissent des insights sur cette session.
• Session utilisateur <-> votre application : établie une fois que l'utilisateur s'est connecté à votre application, souvent à l'aide de Se connecter avec Google. Votre application gère cette session à l'aide des revendications pour améliorer les décisions de gestion des sessions et des comptes.

Les utilisateurs interagissent souvent avec les services Google sur plusieurs appareils, tels que des téléphones, des ordinateurs de bureau, des écrans connectés ou des téléviseurs. Se connecter sur chaque plate-forme ou appareil établit une session distincte. Pour les connexions Web, une session est établie entre le navigateur spécifique et Google. Notez que les modes navigation privée et navigation incognito créent leurs propres sessions distinctes et isolées. Par conséquent, un même compte Google peut avoir plusieurs sessions distinctes actives simultanément sur différents navigateurs et appareils. Pour en savoir plus, consultez Voir les appareils ayant accès au compte.

État du compte Google

Voici les événements typiques du cycle de vie d'un compte Google :

• une personne choisit de créer un compte Google, puis
• Google peut désactiver le compte ou un utilisateur peut le réactiver après avoir suivi Récupérer votre compte Google ou Gmail.
• Une personne peut décider de supprimer son compte Google ou Google peut le supprimer en raison de la règle concernant les comptes Google inactifs.

Les fonctionnalités du pack Sécurité décrites dans ce guide s'appliquent aux comptes actifs ou désactivés, mais pas aux événements de création ou de suppression de comptes Google.

Google peut désactiver un compte à tout moment. Pour en savoir plus, consultez Votre compte est désactivé. Dans ce cas, toutes les sessions Google actives sont interrompues et un événement RISC est envoyé par le service de protection multi-comptes de Google. Les comptes désactivés ne peuvent pas utiliser Se connecter avec Google. Cela signifie qu'un jeton d'identité n'est jamais émis et ne peut donc pas être utilisé pour surveiller les comptes utilisateur désactivés.

La réception d'événements RISC (Protection multicompte) est facultative, mais ces événements constituent des signaux importants pour gérer la session entre l'utilisateur et votre application, et pour déterminer si elle est active. Pour savoir comment implémenter RISC et répondre aux événements, consultez Protéger les comptes utilisateur avec Protection multicompte.

Configuration

Pour recevoir des revendications supplémentaires, votre application doit être publiée, validée et les fonctionnalités du bundle de sécurité doivent être activées. Commencez par vérifier que votre application est publiée et validée :

1. Ouvrez Google Auth Platform.
2. Sélectionner ou créer le projet pour votre application
3. Cliquez sur Audience et vérifiez que l'état de publication est défini sur En production.
4. Cliquez sur Centre de validation et vérifiez que l'état de la validation est Validé.

Ensuite, activez les revendications supplémentaires :

1. Cliquez sur Paramètres dans le menu.
2. Sous Paramètres avancés, sélectionnez :
   • Revendications liées à l'ancienneté de la session pour activer auth_time
   • Revendications de niveau d'authentification pour activer amr

Pour en savoir plus, consultez le Centre d'aide sur la validation des applications OAuth.

Fonctionnalités compatibles

Cette section décrit les fonctionnalités individuelles qui composent le pack Sécurité.

Références des méthodes d'authentification

Authentication Methods References (amr) est une revendication OpenID Connect qui décrit les méthodes utilisées lors du dernier événement d'authentification entre l'utilisateur et Google.

Parmi les valeurs IANA.AMR possibles, Google accepte les valeurs suivantes qui indiquent :

• hwk une clé de sécurité matérielle a été utilisée.
• mfa Authentification multifacteur effectuée
• Un mot de passe a été utilisé par pwd
• Une clé logicielle telle qu'une clé d'accès a été utilisée.swk
• sms un SMS a été utilisé pour la validation
• tel un appel téléphonique a été utilisé pour la validation.

Une ou plusieurs de ces valeurs sont renvoyées sous forme de tableau de chaînes JSON dans la revendication amr du jeton d'identité.

La revendication amr n'est incluse dans le jeton d'identité que lorsque des informations sont disponibles sur la méthode d'authentification utilisée. Elle peut ne pas être présente même si elle est demandée.

Les propriétaires de comptes Google peuvent choisir d'exiger la validation en deux étapes et les méthodes MFA à utiliser. Lorsqu'un compte Google est associé à la protection avancée, une méthode d'A2F renforcée est requise, comme les clés de sécurité Titan (hwk) ou les clés d'accès (swk). Dans les deux cas, la valeur mfa est présente lorsque plusieurs facteurs sont utilisés lors de la connexion au compte Google.

La présence de mfa confirme que l'événement d'authentification répond aux exigences de Google concernant l'authentification multifacteur. Par exemple, une authentification de compte Google avec un mot de passe (pwd) et une clé d'accès (swk) génère la revendication "amr": ["mfa", "pwd", "swk"].

Ces ressources contiennent plus d'informations sur la sécurité des comptes et l'authentification des utilisateurs : Renforcer la sécurité de votre compte Google grâce au programme Protection Avancée, Se connecter avec une clé d'accès au lieu d'un mot de passe et Utiliser une clé de sécurité pour la validation en deux étapes.

Les administrateurs Workspace contrôlent la règle d'authentification pour les comptes Workspace gérés. Ils peuvent exiger l'authentification multifacteur ou l'utilisation de clés de sécurité. Pour en savoir plus, consultez Présentation de la gestion des identités Google, Exigence d'authentification multifactorielle pour Google Cloud et Protections et contrôles de connexion.

Heure d'authentification

La revendication auth_time est une partie standard du protocole OpenID Connect qui fournit des informations sur la dernière authentification de l'utilisateur final auprès de Google. Il s'agit d'un nombre JSON représentant le nombre de secondes écoulées depuis l'époque Unix (1er janvier 1970, 00:00:00 UTC) et correspond à la date de la dernière authentification de l'utilisateur. Il s'agit d'un code temporel indiquant la dernière connexion de l'utilisateur à son compte Google depuis l'appareil ou le navigateur actuel. Cette revendication est incluse dans le jeton d'identité, qui est un jeton Web JSON (JWT) contenant des informations vérifiées sur l'authentification et l'utilisateur.

La revendication auth_time est utile pour votre application, car elle vous permet de déterminer la date de la dernière connexion active d'un utilisateur à un compte Google sur l'appareil ou le navigateur qu'il utilise. Cela peut être particulièrement important pour des raisons de sécurité, par exemple :

• Prendre une décision éclairée quant à savoir si votre application doit émettre une demande d'authentification renforcée supplémentaire avant d'effectuer des actions utilisateur sensibles, comme la suppression du compte, la modification des méthodes de contact du compte ou l'exécution d'un paiement. Google n'accepte pas les demandes de réauthentification de compte Google.

• Utiliser la fraîcheur et la stabilité de la session de compte Google de l'utilisateur comme signal de confiance. En règle générale, une valeur auth_time récente indique la fraîcheur, tandis qu'une valeur plus ancienne indique la stabilité.

Pour les applications Web, la combinaison du navigateur et du système d'exploitation de l'utilisateur constitue une session une fois que l'utilisateur s'est connecté à son compte Google. De son côté, votre site Web gère également une session utilisateur distincte. Une valeur auth_time plus récente indique que l'utilisateur s'est récemment connecté à son compte Google. Il s'agit souvent d'un indicateur d'utilisateur actif et engagé, qui peut être interprété comme un signal de risque plus faible.

Sur les plates-formes mobiles telles qu'Android, les utilisateurs se connectent généralement directement à leur appareil à l'aide de méthodes biométriques telles que la reconnaissance d'empreinte digitale ou faciale, ainsi que des codes ou schémas de déverrouillage spécifiques à l'appareil. Les applications et plates-formes mobiles utilisent souvent ces méthodes d'authentification basées sur la plate-forme plutôt que de créer une session avec Google. Par conséquent, les connexions au compte Google sont peu fréquentes et les mises à jour de auth_time sont rares. Ainsi, une valeur auth_time récente peut signaler une modification d'une session de compte Google de longue durée et donc un risque accru.

Les signaux de confiance sont un sujet nuancé. auth_time doit être utilisé avec d'autres signaux, comme l'activation de l'authentification multifacteur (MFA), la méthode d'authentification utilisée et la durée de la session utilisateur entre votre application et votre plate-forme.

Requêtes

La méthode spécifique utilisée pour demander les revendications auth_time et amr diffère selon l'API utilisée. Toutefois, chaque API inclut un paramètre claims facultatif pour demander auth_time et amr.

https://accounts.google.com/o/oauth2/v2/auth?
response_type=id_token&
client_id=YOUR_CLIENT_ID&
scope=openid email profile&
redirect_uri=https://example.com/user-login&
nonce=123-456-7890&
claims={ "id_token": {
            "auth_time": { "essential":true },
            "amr": {"essential":true}
          }
        }

<html>
<body>
  <script src="https://accounts.google.com/gsi/client" async></script>
  <script>
    window.onload = function () {
      google.accounts.id.initialize({
        client_id: "YOUR_WEB_CLIENT_ID",
        callback: function(rsp) { console.log(rsp.credential); },
        essential_claims: "auth_time, amr",
      });
      google.accounts.id.renderButton(
        document.getElementById("buttonDiv"),
        { type: "standard", size: "large" }
      );
    }
  </script>
  <div id="buttonDiv"></div>
</body>
</html>

val googleIdOption: GetGoogleIdOption = GetGoogleIdOption.Builder()
    .setAutoSelectEnabled(true)
    .setFilterByAuthorizedAccounts(true)
    .setServerClientId(WEB_CLIENT_ID)
    .setNonce("NONCE")
    .setClaims(ImmutableList.of(
           new Claim("auth_time", true),
           new Claim("amr", true)
    ))
    .build()

let authTimeClaim = GIDClaim.authTime()
let amrClaim = GIDClaim.amr()
let claims = Set([authTimeClaim, amrClaim])


// Start the sign-in process
GIDSignIn.sharedInstance.signIn(
  withPresenting: rootViewController,
  claims: claims
) { signInResult, error in
  guard let result = signInResult else {
    print("Error signing in: (error?.localizedDescription ?? "No error description")")
    return
  }
  // If sign in succeeded, display the app's main content View
  print("ID Token: (result.user.idToken?.tokenString ?? "No token")")
}

GIDClaim *authTimeClaim = [GIDClaim authTimeClaim];
GIDClaim *AMRClaim = [GIDClaim AMRClaim];
NSSet *claims = [NSSet setWithArray:@[authTimeClaim, AMRClaim]];


// Include the claims set and start the sign-in process
[GIDSignIn.sharedInstance
  signInWithPresentingViewController:self
                                hint:nil
                              claims:claims
                          completion:^(GIDSignInResult * _Nullable signInResult,
                                      NSError * _Nullable error) {
                            // On success signInResult.user.idToken
                            // contains the requested claims.
                          }];

Réponses

Lorsque les revendications auth_time ou amr sont incluses dans la requête, elles sont renvoyées dans la réponse de charge utile du jeton d'identité, ainsi que d'autres revendications standards telles que iss (émetteur), sub (sujet), aud (audience) et exp (délai d'expiration).

Les revendications manquantes sont probablement dues au fait que l'application n'est pas validée ou que des paramètres supplémentaires sont désactivés (par défaut). Suivez les instructions de la section Configuration pour vérifier que l'ID client et l'application utilisée sont validés, et que les revendications supplémentaires sont activées.

La valeur de la revendication auth_time est un nombre JSON représentant le nombre de secondes écoulées depuis l'époque Unix (1er janvier 1970, 00:00:00 UTC) jusqu'à la dernière authentification de l'utilisateur.

La valeur de la revendication amr est un tableau JSON de chaînes représentant les méthodes d'authentification utilisées lors du dernier événement de connexion au compte Google.

Voici un exemple de jeton d'identité décodé qui inclut les revendications auth_time et amr :

{
  "iss": "https://accounts.google.com",
  "azp": "YOUR_CLIENT_ID",
  "aud": "YOUR_CLIENT_ID",
  "sub": "117726431651943698600",
  "email": "alice@example.com",
  "email_verified": true,
  "nonce": "123-456-7890",
  "auth_time": 1748875426,
  "amr": ["mfa", "pwd", "tel"],
  "nbf": 1748880889,
  "name": "Elisa Beckett",
  "picture": "https://lh3.googleusercontent.com/a/default-user=s96-c",
  "given_name": "Elisa",
  "family_name": "Beckett",
  "iat": 1748881189,
  "exp": 1748884789,
  "jti": "8b5d7ce345787d5dbf14ce6e08a8f88ee8c9b5b1"
}

Le jeton d'identité contient également une revendication iat (émis à) qui indique l'heure à laquelle le jeton JWT a été émis. En comparant les revendications iat et auth_time, vous pouvez déterminer le temps écoulé depuis la dernière authentification de l'utilisateur par rapport au moment où le jeton d'identité spécifique a été créé. Par exemple, si iat est défini sur 1748881189 et auth_time sur 1748875426, la différence est de 5 763 secondes, ce qui représente 1 heure, 36 minutes et 3 secondes de temps écoulé.