AWS Cognito : gestion des utilisateurs et authentification
AWS Cognito offre une solution fiable et évolutive pour la gestion des utilisateurs et l'authentification des applications web et mobiles, sans avoir à exploiter un backend d'identité propre. Le service intègre des fournisseurs d'identité externes et fournit des jetons conformes aux standards pour les API. De plus, il permet l'échange de jetons d'identité contre des identifiants temporaires AWS pour un accès direct à des services AWS tels que S3 et DynamoDB.
Quelle: Affichage personnalisé
Notions de base d'AWS Cognito
AWS Cognito se compose de deux composants principaux : les pools d'utilisateurs et les pools d'identité.
Pools d'utilisateurs sont un annuaire d'utilisateurs et un OpenID-Connect-kompatibler Identity Provider. Ils authentifient les utilisateurs, émettent des jetons d'identité (ID), d'accès et de rafraîchissement et intègrent des fournisseurs d'identité sociaux ou d'entreprise via OIDC ou SAML.
Pools d'identité (également appelés identités fédérées) fournissent sur la base de ces identités kurzlebige AWS-Credentials. Ceci est également possible pour les invités qui ne sont pas encore connectés.
La page d'inscription gérée, autrefois connue sous le nom de « Hosted UI » et aujourd'hui appelée « Managed Login », est prête, y compris
standardkonforme OAuth-Endpunkte prêt, y compris
/oauth2/authorize, /oauth2/token, /logout ainsi que la découverte OIDC- OIDC Discovery- et JWKS-Ressourcen.
Pour les applications à page unique (SPAs), le
Authorization-Code-Flow mit PKCE est d'une importance centrale, car il empêche que des codes interceptés soient détournés et utilisés.
Les jetons émis sont JSON Web Tokens (JWTs). Les jetons d’accès transportent les scopes et les groupes pour l’autorisation des API, tandis que les jetons d’identité contiennent des informations de profil. Les signatures de ces jetons peuvent être vérifiées à l’aide de l’URL JWKS du pool concerné.
État actuel et fonctionnalités
Les durées de vie des jetons peuvent être réglées avec précision par client d'application. Les jetons d’accès et d’identité peuvent être entre 5 Minuten und 1 Tag peuvent être configurées. Les jetons d’actualisation ont par défaut une validité de 30 jours, qui peut toutefois être ajustée entre 60 Minuten und 10 Jahren puis être ajustée.
Les pages de gestion de connexion prennent en charge PKCE standardmäßig. Le Logout-Endpunkt met fin à la session du navigateur et redirige vers les URL de déconnexion configurées.
Quelle: aws.amazon.com
Aperçu des principales fonctionnalités d’Amazon Cognito.
Pour une personnalisation de la marque et l'utilisation de ses propres domaines, une Custom Domain mit einem ACM-Zertifikat peut être configurée (certificat dans us-east-1 requis). Ensuite, la connexion se fait via le sous-domaine personnalisé.
Les API peuvent soit être protégées directement au niveau d'API Gateway avec un JWT-Authorizer protéger, qui accepte Cognito comme émetteur OIDC, ou par un authorizer (Lambda) personnalisé.
Le adaptive/risikobasierte Anmeldung („Threat Protection“) peut évaluer les tentatives de connexion suspectes, imposer une authentification multi-facteurs (MFA) ou bloquer les accès.
Pour les applications multi-tenant, AWS documente différents schémas, allant d'un Single-Pool-Ansatz bis hin zu einem Pool pro Tenant, incluant l'isolation via des groupes/rôles et des scopes.
L’intégration dans les applications Next.js est facilitée par le Cognito-Provider von NextAuth facilitée. Les sessions sont gérées via des JWT/Cookies, et l’Edge-Middleware protège les routes.
Contexte et motivation
Les applications modernes nécessitent une couche d'identité centrale qui prend en charge les standards industriels tels que OIDC/OAuth2/SAML prise en charge, aborde les risques liés à MFA et à l'authentification adaptative et permet en même temps l’intégration de ses propres fournisseurs d'identité. Pour les SPAs, c’est PKCE unverzichtbar, que les secrets côté client ne peuvent pas être stockés en sécurité dans le navigateur; Cognito implémente pleinement PKCE.
Du côté API, le direct JWT-Abgleich am API Gateway est attractif. Il offre une faible latence, une séparation claire entre l’authentification (AuthN) et l’autorisation (AuthZ) et évite un aller-retour supplémentaire vers le magasin des utilisateurs.
La conformité et la résidence des données sont d'autres aspects importants. Les pools d'utilisateurs stockent les données de profil au niveau régional. Des fonctionnalités optionnelles comme Pinpoint Analytics peuvent envoyer des données dans d'autres régions, ce qui est pertinent pour les équipes EU/CH et besondere Beachtung erfordert.
Quelle: YouTube
Cette démonstration guidée montre le SAML-Föderation mit Cognito, ce qui peut être utile pour comprendre visuellement les scénarios basés sur IdP et le Single Logout.
Utilisation pratique & recommandations
Si vous développez une SPA ou une application Next.js, vous devriez choisir le Authorization Code Flow mit PKCE choisir. Les jetons devraient être stockés côté serveur dans des cookies httpOnly ou utiliser le mécanisme de session du framework. La vérification des JWT devrait toujours être contre le JWKS-Endpunkt des Pools avoir lieu.
Quelle: economize.cloud
Flux d'authentification type avec AWS Cognito.
Les API devraient vérifier les scopes et un JWT-Authorizer utiliser pour dissocier l’authentification et l’autorisation et réduire les latences.
Pour les applications multi-tenant, il est conseillé de commencer par un Single-Pool-Ansatz à compléter par des attributs de mandant ou des scopes. En cas d’exigences strictes en matière d’isolation, une pool par tenant peut être envisagée.
Dans le domaine des opérations, il est recommandé, CloudTrail und CloudWatch-Metriken d'activer, de surveiller les quotas et les modèles de connexion et, éventuellement, le Threat Protection utiliser.
En matière de conformité, les flux de données régionaux (par exemple via Analytics) doivent être vérifiés et documentés pour les équipes EU/CH, en particulier en prenant en compte les regionalen Datenüberlegungen.
Quelle: YouTube
Cette démonstration guidée aide à comprendre le Authorization-Code-Flow mit PKCE de bout en bout.
Questions ouvertes et défis
La conception de TTL des jetons et de leur rotation doit être soigneusement pesée pour trouver un équilibre entre l’UX et le niveau de sécurité, sans obliger les applications à des rafraîchissements constants. AWS recommande d’utiliser les jetons pour environ 75 Prozent ihrer Lebenszeit et de les renouveler seulement ensuite.
La question se pose de savoir jusqu'où l'isolation des mandants via des groupes/scopes est suffisante avant qu'un découpage des pools devienne nécessaire sur le plan organisationnel et financier. AWS décrit les deux voies, mais les seuils fiables sont anwendungsabhängig.
Quelle: aws.amazon.com
Intégration de Cognito avec des fournisseurs d'identité externes et des services AWS.
Quelles données peuvent être exportées hors de leur région selon les règles de conformité, lorsque des fonctionnalités optionnelles comme Pinpoint sont activées ? Voici les regionalen Hinweise à vérifier et les opt-ins à documenter.
La cohérence du Single Logout sur tous les IdPs connectés constitue un autre défi. Pour SAML, il existe SLO-Unterstützung, cependant les détails d’implémentation varient selon l’IdP.
Conclusion : AWS Cognito offre un noyau d'authentification solide, conforme aux normes, avec des points d'extension clairs : connexion gérée avec PKCE, vérification JWT propre et fédération optionnelle vers des IdPs sociaux ou d'entreprise. Dans la pratique, il est crucial de choisir le flux adapté à l'application, de limiter délibérément la durée des jetons et d'autoriser l'API couche strictement via des scopes. En planifiant des architectures multi-tenant, il faut prendre des décisions tôt sur les frontières d'isolation et les métriques opérationnelles. Les briques sont en place, la décision de conception appartient à l'utilisateur.