Comprendre finement comment Google
vous authentifie — et autorise.

Toute la redirection existe pour ça : l'utilisateur tape son mot de passe sur accounts.google.com, en TLS, jamais sur votre application. Votre serveur ne voit ni le mot de passe, ni le second facteur.

Ce que fait Google (côté serveur d'autorisation)

• Réception du mot de passe sur une connexion TLS vers un domaine Google.
• Vérification contre un hash salé et étiré (fonction lente de type scrypt/dérivée + pepper côté serveur) — le mot de passe en clair n'est jamais stocké.
• Défi MFA éventuel (TOTP, clé de sécurité WebAuthn/FIDO2, prompt sur mobile).
• Succès → Google pose un cookie de session sur .google.com et émet le code d'autorisation. Votre app ne reçoit que ce code.

C'est ce cookie de session Google qui explique qu'aux connexions suivantes, l'écran ne redemande pas le mot de passe : Google vous reconnaît déjà, il ne reste que le consentement aux scopes.

Le code transite par le navigateur : il peut être intercepté (extension malveillante, redirection piégée). PKCE (RFC 7636) neutralise le vol : le code ne vaut rien sans un secret que seule votre app connaît, et qui n'a jamais transité en clair.

• code_verifier : chaîne aléatoire à forte entropie, 43 à 128 caractères non réservés. Généré et gardé par l'app, jamais envoyé à l'étape 1.
• code_challenge = BASE64URL( SHA256( code_verifier ) ), avec code_challenge_method=S256. C'est lui seul qui part dans la requête d'autorisation.

# 1. code_verifier : aléatoire, non réservé
code_verifier=$(openssl rand -base64 96 | tr -d '\n=+/' | cut -c1-64)

# 2. code_challenge = BASE64URL( SHA256(code_verifier) )
code_challenge=$(printf '%s' "$code_verifier" \
  | openssl dgst -binary -sha256 \
  | openssl base64 | tr -d '=' | tr '/+' '_-')

À l'échange (étape 6), l'app envoie le code_verifier. Google recalcule SHA256(code_verifier) et le compare au code_challenge mémorisé à l'étape 1. Un attaquant qui a volé le code n'a pas le verifier → l'échange échoue. SHA-256 étant à sens unique, le challenge intercepté ne permet pas de retrouver le verifier.

Deux identifiants distincts, émis à l'enregistrement de l'app dans Google Cloud :

• client_id — public (ex. 1234-abc.apps.googleusercontent.com). Il identifie l'app, apparaît dans l'URL, et devient l'aud de l'id_token.
• client_secret — un secret partagé entre votre serveur et Google. Présenté au token endpoint pour prouver que l'échange vient bien de la vraie app.

Il s'envoie soit en en-tête HTTP Basic, soit dans le corps du POST :

# Variante HTTP Basic (recommandée)
Authorization: Basic BASE64( client_id ":" client_secret )

# Variante corps de requête
client_id=1234-abc.apps.googleusercontent.com&client_secret=GOCSPX-...

• state — valeur aléatoire liée à la session du navigateur, renvoyée telle quelle par Google. L'app la recompare au retour : si elle ne correspond pas, la réponse a été injectée par un tiers → anti-CSRF.
• nonce — valeur aléatoire envoyée à l'étape 1 ; Google la réinjecte dans l'id_token. L'app vérifie que le nonce du token correspond à celui qu'elle a émis → un ancien id_token rejoué ne passe pas : anti-rejeu, et liaison de l'id_token à cette requête précise.

L'id_token est un JWS : Google le signe avec sa clé privée RSA, votre app le vérifie avec la clé publique correspondante — sans jamais rejouer d'appel à Google (les clés sont mises en cache).

Comment Google le signe

signing_input = BASE64URL(header_json) + "." + BASE64URL(payload_json)
signature     = RSASSA-PKCS1-v1_5( SHA-256, cléPrivéeGoogle, signing_input )
id_token      = signing_input + "." + BASE64URL(signature)

// header : { "alg":"RS256", "kid":"a1b2c3d4", "typ":"JWT" }
// le kid identifie LAQUELLE des clés publiques a servi

Comment votre app le vérifie

1. Lire le kid du header → choisir la bonne clé publique dans le JWKS (https://www.googleapis.com/oauth2/v3/certs, mis en cache selon les en-têtes HTTP).
2. Recomposer signing_input, calculer son SHA-256, et vérifier la signature RSA avec la clé publique (n, e).
3. Signature valide → valider les claims : iss, aud=votre client_id, exp non dépassé, nonce attendu.

from google.oauth2 import id_token
from google.auth.transport import requests

# récupère le JWKS, choisit la clé via kid, vérifie la
# signature RSA + iss/aud/exp — lève une exception sinon
claims = id_token.verify_oauth2_token(token, requests.Request(), CLIENT_ID)
print(claims["email"], claims["sub"])

Rotation : Google fait tourner ses clés régulièrement. Le kid permet de conserver plusieurs clés valides simultanément et de basculer sans casser les vérifications en cours. Décodez un id_token vous-même en section 07.

Ici aucun mot de passe, aucun utilisateur. La preuve d'identité est purement cryptographique : le programme détient la clé privée du SA, il signe un JWT, Google vérifie avec la clé publique qu'il connaît déjà.

1. Ce que contient le fichier de clé JSON

{
  "type": "service_account",
  "private_key_id": "a1b2c3d4...",      // → devient le kid du JWT
  "private_key": "-----BEGIN PRIVATE KEY-----\n...",
  "client_email": "sa@projet.iam.gserviceaccount.com",
  "token_uri": "https://oauth2.googleapis.com/token"
}

2. Le programme forge et signe le JWT (RS256)

header = { "alg":"RS256", "typ":"JWT", "kid": private_key_id }
claims = {
  "iss": "sa@projet.iam.gserviceaccount.com",   // = client_email
  "sub": "sa@projet.iam.gserviceaccount.com",
  "aud": "https://oauth2.googleapis.com/token",  // le destinataire
  "scope": "https://www.googleapis.com/auth/cloud-platform",
  "iat": now, "exp": now + 3600           // ≤ 1 h
}
signing_input = BASE64URL(header) + "." + BASE64URL(claims)
assertion     = signing_input + "." +
                BASE64URL( RSA_sign(SHA-256, private_key, signing_input) )

3. Échange contre un access token

POST https://oauth2.googleapis.com/token
grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer&
assertion=<le JWT signé ci-dessus>

4. Comment Google vérifie

Google lit le kid, récupère la clé publique du SA correspondante (publiée sur https://www.googleapis.com/robot/v1/metadata/x509/<email-du-sa>), vérifie la signature RSA, contrôle aud/exp, puis renvoie l'access token. La clé privée, elle, ne quitte jamais votre programme.

Le point subtil : le JWT présenté vient d'un émetteur externe (GitHub, AWS…). Google ne l'a pas signé et n'a pas la clé privée. La confiance est établie une fois, à la configuration du provider, puis vérifiée à chaque échange.

Ce que déclare le provider (configuration, une fois)

• L'issuer URI de l'IdP externe (ex. https://token.actions.githubusercontent.com).
• Les audiences autorisées du jeton externe.
• Un mapping d'attributs (claims externes → attributs Google, ex. google.subject = assertion.sub).
• Une condition d'attributs en CEL, ex. n'accepter que tel dépôt/branche.

À chaque échange (runtime)

1. STS lit le iss du JWT externe, récupère la découverte OIDC de cet émetteur (/.well-known/openid-configuration) puis son JWKS, et vérifie la signature du jeton avec la clé publique de l'IdP externe (sélectionnée par kid).
2. Contrôle des claims : iss attendu, aud autorisée, exp non dépassé.
3. Application du mapping d'attributs, puis évaluation de la condition CEL — si elle est fausse, l'échange est refusé.
4. Émission d'un access token fédéré, courte durée, portée réduite.

attribute.repository == "mon-org/mon-repo" &&
assertion.ref == "refs/heads/main"

Cas AWS : pas d'OIDC. La charge présente une requête GetCallerIdentity signée (SigV4) ; STS la relaie à AWS pour prouver l'identité IAM appelante, puis applique le même mapping/condition.