Authentifier les utilisateurs finaux avec Amazon Cognito

Déployer des applications sur AWS

Dunieski Otano

Amazon Web Services Solutions Architect

Créer votre propre login ?

Nouvelle appli : inscription et connexion complètes
L'équipe veut coder l'authentification de zéro
Cognito le fait déjà, et en toute sécurité

Choisir l'authentification gérée Amazon Cognito plutôt que créer un login sur mesure

User pools vs identity pools

User Pool Cognito comme annuaire émettant des jetons à gauche, Identity Pool échangeant un jeton validé contre des identifiants AWS temporaires au centre, services AWS à droite

User pool : annuaire géré des utilisateurs finaux
Gère inscription, connexion et émet des tokens
Identity pool : échange un login contre des identifiants AWS
À utiliser ensemble : authentifier puis autoriser l'accès AWS

Les trois jetons Cognito

ID token : qui est l'utilisateur (revendications d'identité)
Access token : ce que l'utilisateur peut appeler
Refresh token : obtenir de nouveaux jetons sans se reconnecter
Les trois sont des JWT décodables et vérifiables

Trois jetons JWT Cognito côte à côte : ID token avec revendications d'identité, access token avec périmètres d'API, refresh token longue durée pour un renouvellement silencieux

Identité fédérée

Fédération : se connecter via un fournisseur d'identité externe
Réseaux sociaux : Google, Facebook, Apple
Entreprise : fournisseurs SAML et OIDC
Cognito assure la confiance et émet ses propres jetons

Fédération Cognito : l'utilisateur choisit un fournisseur social (Google, Facebook) ou d'entreprise SAML/OIDC, Cognito valide la connexion externe et émet ses propres jetons standard

Cognito comme authorizer d'API Gateway

Autorisation Cognito d'API Gateway : le client envoie l'en-tête Authorization avec l'access token, la passerelle valide auprès du user pool avant Lambda ; tokens invalides rejetés en 401

API Gateway peut utiliser un Cognito authorizer
Le client envoie son jeton dans l'Authorization header
API Gateway valide le jeton avant le backend
Tokens invalides ou expirés rejetés en périphérie

Flux type : connexion puis appel d'API

L'utilisateur se connecte au user pool
Reçoit les jetons ID, access et refresh
Le client appelle API Gateway avec l'access token
L'authorizer Cognito valide, puis le backend s'exécute

Flux connexion → appel API : l'utilisateur se connecte au user pool et reçoit des jetons ; le client envoie l'access token à API Gateway ; l'authorizer Cognito le valide ; la Lambda backend s'exécute

Erreurs Cognito fréquentes

Envoyer l'ID token là où l'access token est requis
Confondre user pools et identity pools
Tenter d'autoriser l'accès AWS avec un user pool seul
Stocker les jetons de façon non sécurisée côté client

Erreurs courantes avec Cognito : envoyer l'ID token à une API au lieu de l'access token, confondre user pool et identity pool, et stocker les jetons de façon non sécurisée côté client

Passons à la pratique !