Comment fonctionne l'authentification avec Amazon Cognito - Amazon Cognito
SDKauthentificationAuthentification de l'interface utilisateurAuthentification par un fournisseur d'identité tiersAuthentification du pool d'identités

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Comment fonctionne l'authentification avec Amazon Cognito

Lorsque votre client se connecte à un groupe d'utilisateurs Amazon Cognito, votre application reçoit des jetons JSON Web ()JWTs.

Lorsque votre client se connecte à un pool d'identités, soit avec un jeton de groupe d'utilisateurs, soit avec un autre fournisseur, votre application reçoit des AWS informations d'identification temporaires.

Avec la connexion au groupe d'utilisateurs, vous pouvez implémenter l'authentification et l'autorisation entièrement avec un AWS SDK. Si vous ne souhaitez pas créer vos propres composants d'interface utilisateur (UI), vous pouvez appeler une interface utilisateur Web prédéfinie (l'interface utilisateur hébergée) ou la page de connexion de votre fournisseur d'identité tiers (IdP).

Cette rubrique présente certaines des manières dont votre application peut interagir avec Amazon Cognito pour s'authentifier à l'aide de jetons d'identification, autoriser à l'aide de jetons d'accès et accéder à l'aide des informations d'identification du pool Services AWS d'identités.

APIAuthentification et autorisation du groupe d'utilisateurs à l'aide d'un AWS SDK

AWS a développé des composants pour les groupes d'utilisateurs Amazon Cognito, ou fournisseur d'identité Amazon Cognito, dans divers frameworks de développement. Les méthodes intégrées à ces méthodes font SDKs appel aux groupes d'utilisateurs Amazon Cognito. API Le même espace de API noms de groupes d'utilisateurs comporte des opérations pour la configuration des groupes d'utilisateurs et pour l'authentification des utilisateurs. Pour une présentation plus complète, voirUtilisation des groupes d'utilisateurs API et du serveur d'autorisation.

APIl'authentification s'adapte au modèle dans lequel vos applications possèdent des composants d'interface utilisateur existants et s'appuient principalement sur le pool d'utilisateurs en tant qu'annuaire d'utilisateurs. Cette conception ajoute Amazon Cognito en tant que composant au sein d'une application plus vaste. Cela nécessite une logique programmatique pour gérer des chaînes complexes de défis et de réponses.

Cette application n'a pas besoin d'implémenter une implémentation complète d'OpenID Connect (OIDC) s'appuyant sur une partie. Au lieu de cela, il a la capacité de décoder et d'utiliserJWTs. Si vous souhaitez accéder à l'ensemble des fonctionnalités du pool d'utilisateurs pour les utilisateurs locaux, créez votre authentification avec Amazon Cognito SDK dans votre environnement de développement.

APIl'authentification avec des OAuth étendues personnalisées est moins orientée vers l'APIautorisation externe. Pour ajouter des étendues personnalisées à un jeton d'accès à partir de API l'authentification, modifiez le jeton au moment de l'exécution avec unDéclencheur Lambda avant génération de jeton.

Le schéma suivant illustre une session de connexion typique pour API l'authentification.

Un organigramme qui montre une application qui invite un utilisateur à saisir des données et le connecte à l'aide d'un. AWS SDK
APIflux d'authentification

  1. Un utilisateur accède à votre application.

  2. Ils sélectionnent un lien « Se connecter ».

  3. Ils saisissent leur nom d'utilisateur et leur mot de passe.

  4. L'application invoque la méthode qui fait une InitiateAuthAPIdemande. La demande transmet les informations d'identification de l'utilisateur à un groupe d'utilisateurs.

  5. Le groupe d'utilisateurs valide les informations d'identification de l'utilisateur et détermine que celui-ci a activé l'authentification multifactorielle ()MFA.

  6. Le groupe d'utilisateurs répond par un défi qui demande un MFA code.

  7. L'application génère une invite qui collecte le MFA code auprès de l'utilisateur.

  8. L'application invoque la méthode qui fait une RespondToAuthChallengeAPIdemande. La demande transmet le MFA code de l'utilisateur.

  9. Le groupe d'utilisateurs valide le MFA code de l'utilisateur.

  10. Le groupe d'utilisateurs répond avec celui de l'utilisateurJWTs.

  11. L'application décode, valide et stocke ou met en cache ceux de l'utilisateur. JWTs

  12. L'application affiche le composant à accès contrôlé demandé.

  13. L'utilisateur consulte leur contenu.

  14. Plus tard, le jeton d'accès de l'utilisateur a expiré et l'utilisateur demande à consulter un composant dont l'accès est contrôlé.

  15. L'application détermine que la session de l'utilisateur doit être maintenue. Il invoque à nouveau la InitiateAuthméthode avec le jeton d'actualisation et récupère de nouveaux jetons.

Variantes et personnalisation

Vous pouvez ajouter des défis supplémentaires à ce flux, par exemple vos propres défis d'authentification personnalisés. Vous pouvez restreindre automatiquement l'accès aux utilisateurs dont les mots de passe ont été compromis ou dont les caractéristiques de connexion inattendues peuvent indiquer une tentative de connexion malveillante. Ce flux est sensiblement le même pour les opérations d'inscription, de mise à jour des attributs utilisateur et de réinitialisation des mots de passe. La plupart de ces flux comportent des opérations publiques (côté client) et confidentielles (côté serveur) dupliquées. API

Ressources connexes

Authentification du groupe d'utilisateurs avec l'interface utilisateur hébergée

L'interface utilisateur hébergée est un site Web lié à votre groupe d'utilisateurs et à votre client d'application. Il peut effectuer des opérations de connexion, d'inscription et de réinitialisation du mot de passe pour vos utilisateurs. La mise en œuvre d'une application dotée d'un composant d'interface utilisateur hébergé pour l'authentification peut nécessiter moins d'efforts de développement. Une application peut ignorer les composants de l'interface utilisateur à des fins d'authentification et invoquer l'interface utilisateur hébergée dans le navigateur de l'utilisateur.

Les applications collectent les utilisateurs JWTs avec un emplacement de redirection vers le Web ou une application. Les applications qui implémentent l'interface utilisateur hébergée peuvent se connecter aux groupes d'utilisateurs pour s'authentifier comme s'il s'agissait d'un OIDC IdP OpenID Connect ().

L'authentification par interface utilisateur hébergée s'adapte au modèle dans lequel les applications ont besoin d'un serveur d'autorisation, mais n'ont pas besoin de fonctionnalités telles que l'authentification personnalisée, l'intégration de groupes d'identités ou le libre-service des attributs utilisateur. Lorsque vous souhaitez utiliser certaines de ces options avancées, vous pouvez les implémenter avec un composant de groupes d'utilisateurs pour unSDK.

L'interface utilisateur hébergée et les modèles d'authentification IdP tiers, qui reposent principalement sur la OIDC mise en œuvre, sont les meilleurs pour les modèles d'autorisation avancés dotés d'une portée OAuth 2.0.

Le schéma suivant illustre une session de connexion typique pour l'authentification de l'interface utilisateur hébergée.

Un organigramme qui montre une application qui invite un utilisateur à saisir des informations et le connecte à l'aide de l'interface utilisateur hébergée.
Flux d'authentification de l'interface utilisateur hébergée

  1. Un utilisateur accède à votre application.

  2. Ils sélectionnent un lien « Se connecter ».

  3. L'application dirige l'utilisateur vers une invite de connexion à l'interface utilisateur hébergée.

  4. Ils saisissent leur nom d'utilisateur et leur mot de passe.

  5. Le groupe d'utilisateurs valide les informations d'identification de l'utilisateur et détermine que celui-ci a activé l'authentification multifactorielle ()MFA.

  6. L'interface utilisateur hébergée invite l'utilisateur à saisir un MFA code.

  7. L'utilisateur saisit son MFA code.

  8. L'interface utilisateur hébergée redirige l'utilisateur vers l'application.

  9. L'application collecte le code d'autorisation à partir du paramètre de URL demande que l'interface utilisateur hébergée a ajouté au rappel URL.

  10. L'application demande des jetons avec le code d'autorisation.

  11. Le point de terminaison du jeton revient JWTs à l'application.

  12. L'application décode, valide et stocke ou met en cache ceux de l'utilisateur. JWTs

  13. L'application affiche le composant à accès contrôlé demandé.

  14. L'utilisateur consulte leur contenu.

  15. Plus tard, le jeton d'accès de l'utilisateur a expiré et l'utilisateur demande à consulter un composant dont l'accès est contrôlé.

  16. L'application détermine que la session de l'utilisateur doit être maintenue. Il demande de nouveaux jetons au point de terminaison du jeton avec le jeton d'actualisation.

Variantes et personnalisation

Vous pouvez personnaliser l'apparence de l'interface utilisateur hébergée CSS dans n'importe quel client d'application. Vous pouvez également configurer les clients d'applications avec leurs propres fournisseurs d'identité, leurs propres étendues, leur accès aux attributs utilisateur et leur propre configuration de sécurité avancée.

Ressources connexes

Authentification du groupe d'utilisateurs auprès d'un fournisseur d'identité tiers

La connexion avec un fournisseur d'identité externe (IdP), ou authentification fédérée, est un modèle similaire à l'interface utilisateur hébergée. Votre application est une partie OIDC de confiance de votre groupe d'utilisateurs, tandis que votre groupe d'utilisateurs sert de relais à un IdP. L'IdP peut être un annuaire d'utilisateurs grand public tel que Facebook ou Google, ou un annuaire SAML 2.0 ou d'OIDCentreprise comme Azure.

Au lieu de l'interface utilisateur hébergée dans le navigateur de l'utilisateur, votre application invoque un point de terminaison de redirection sur le serveur d'autorisation du groupe d'utilisateurs. Du point de vue de l'utilisateur, il choisit le bouton de connexion dans votre application. Ensuite, leur IdP les invite à se connecter. Comme dans le cas de l'authentification par interface utilisateur hébergée, une application collecte des données JWTs à un emplacement de redirection dans l'application.

L'authentification auprès d'un IdP tiers correspond à un modèle dans lequel les utilisateurs peuvent ne pas vouloir créer un nouveau mot de passe lorsqu'ils s'inscrivent à votre application. L'authentification tierce peut être ajoutée sans effort à une application qui met en œuvre l'authentification par interface utilisateur hébergée. En effet, l'interface utilisateur hébergée et la tierce partie IdPs produisent un résultat d'authentification cohérent à partir de variations mineures de ce que vous invoquez dans les navigateurs des utilisateurs.

À l'instar de l'authentification par interface utilisateur hébergée, l'authentification fédérée est idéale pour les modèles d'autorisation avancés dotés d'une portée OAuth 2.0.

Le schéma suivant illustre une session de connexion typique pour l'authentification fédérée.

Un organigramme qui montre une application qui invite un utilisateur à saisir des informations et le connecte avec un IdP tiers.
Flux d'authentification fédéré

  1. Un utilisateur accède à votre application.

  2. Ils sélectionnent un lien « Se connecter ».

  3. L'application dirige l'utilisateur vers une invite de connexion avec son IdP.

  4. Ils saisissent leur nom d'utilisateur et leur mot de passe.

  5. L'IdP valide les informations d'identification de l'utilisateur et détermine que celui-ci a activé l'authentification multifactorielle (). MFA

  6. L'IdP invite l'utilisateur à saisir un code. MFA

  7. L'utilisateur saisit son MFA code.

  8. L'IdP redirige l'utilisateur vers le groupe d'utilisateurs avec une SAML réponse ou un code d'autorisation.

  9. Si l'utilisateur a transmis un code d'autorisation, le groupe d'utilisateurs échange silencieusement le code contre des jetons IdP. Le groupe d'utilisateurs valide les jetons IdP et redirige l'utilisateur vers l'application avec un nouveau code d'autorisation.

  10. L'application collecte le code d'autorisation à partir du paramètre de URL demande que le groupe d'utilisateurs a ajouté au rappel URL.

  11. L'application demande des jetons avec le code d'autorisation.

  12. Le point de terminaison du jeton revient JWTs à l'application.

  13. L'application décode, valide et stocke ou met en cache ceux de l'utilisateur. JWTs

  14. L'application affiche le composant à accès contrôlé demandé.

  15. L'utilisateur consulte leur contenu.

  16. Plus tard, le jeton d'accès de l'utilisateur a expiré et l'utilisateur demande à consulter un composant dont l'accès est contrôlé.

  17. L'application détermine que la session de l'utilisateur doit être maintenue. Il demande de nouveaux jetons au point de terminaison du jeton avec le jeton d'actualisation.

Variantes et personnalisation

Vous pouvez lancer l'authentification fédérée dans l'interface utilisateur hébergée, où les utilisateurs peuvent choisir parmi une liste de celles IdPs que vous avez attribuées à votre client d'application. L'interface utilisateur hébergée peut également demander une adresse e-mail et acheminer automatiquement la demande d'un utilisateur vers l'SAMLIdP correspondant. L'authentification auprès d'un fournisseur d'identité tiers ne nécessite aucune interaction de l'utilisateur avec l'interface utilisateur hébergée. Votre application peut ajouter un paramètre de demande à la demande du serveur d'autorisation d'un utilisateur et obliger celui-ci à être redirigé silencieusement vers sa page de connexion IdP.

Ressources connexes

Authentification du pool d'identités

Un pool d'identités est un composant de votre application distinct d'un groupe d'utilisateurs en termes de fonction, d'espace de API noms et de SDK modèle. Lorsque les groupes d'utilisateurs proposent une authentification et une autorisation basées sur des jetons, les pools d'identités offrent une autorisation pour AWS Identity and Access Management ()IAM.

Vous pouvez attribuer un ensemble de deux groupes IdPs d'identités et connecter des utilisateurs à l'aide de ceux-ci. Les groupes d'utilisateurs sont étroitement intégrés en tant que pool d'identités IdPs et offrent aux groupes d'identités le plus grand nombre d'options en matière de contrôle d'accès. Dans le même temps, il existe un large choix d'options d'authentification pour les pools d'identités. Les groupes d'utilisateurs rejoignent les sources d'identité SAMLOIDC, sociales, de développeurs et d'invités pour accéder à des AWS informations d'identification temporaires à partir de pools d'identités.

L'authentification avec un pool d'identités est externe : elle suit l'un des flux du groupe d'utilisateurs illustrés précédemment, ou un flux que vous développez indépendamment avec un autre IdP. Une fois que votre application a effectué l'authentification initiale, elle transmet la preuve à un pool d'identités et reçoit une session temporaire en retour.

L'authentification avec un pool d'identités s'inscrit dans un modèle dans lequel vous appliquez le contrôle d'accès aux actifs et aux données des applications Services AWS avec IAM autorisation. Comme pour l'APIauthentification dans les groupes d'utilisateurs, une application performante inclut AWS SDKs pour chacun des services auxquels vous souhaitez accéder pour le bénéfice de vos utilisateurs. AWS SDKsappliquer les informations d'identification issues de l'authentification du pool d'identités sous forme de signatures aux API demandes.

Le schéma suivant illustre une session de connexion typique pour l'authentification du pool d'identités avec un IdP.

Un organigramme qui montre une application qui invite un utilisateur à saisir des informations et le connecte avec un IdP tiers.
Flux d'authentification fédéré

  1. Un utilisateur accède à votre application.

  2. Ils sélectionnent un lien « Se connecter ».

  3. L'application dirige l'utilisateur vers une invite de connexion avec son IdP.

  4. Ils saisissent leur nom d'utilisateur et leur mot de passe.

  5. L'IdP valide les informations d'identification de l'utilisateur.

  6. L'IdP redirige l'utilisateur vers l'application avec une SAML réponse ou un code d'autorisation.

  7. Si l'utilisateur transmet un code d'autorisation, l'application échange le code contre des jetons IdP.

  8. L'application décode, valide et stocke ou met en cache l'assertion ou l'assertion de JWTs l'utilisateur.

  9. L'application invoque la méthode qui fait une GetIdAPIdemande. Il transmet le jeton ou l'assertion de l'utilisateur et demande un identifiant d'identité.

  10. Le pool d'identités valide le jeton ou l'assertion par rapport aux fournisseurs d'identité configurés.

  11. Le pool d'identités renvoie un identifiant d'identité.

  12. L'application invoque la méthode qui fait une GetCredentialsForIdentityAPIdemande. Il transmet le jeton ou les assertions de l'utilisateur et demande un IAM rôle.

  13. Le pool d'identités en génère un nouveauJWT. Le nouveau JWT contient des revendications qui demandent un IAM rôle. Le pool d'identités détermine le rôle en fonction de la demande de l'utilisateur et des critères de sélection des rôles dans la configuration du pool d'identités pour l'IdP.

  14. AWS Security Token Service (AWS STS) répond à la AssumeRoleWithWebIdentitydemande du pool d'identités. La réponse contient les API informations d'identification d'une session temporaire avec un IAM rôle.

  15. L'application enregistre les informations d'identification de session.

  16. L'utilisateur effectue une action dans l'application qui nécessite l'accès à des ressources protégées. AWS

  17. L'application applique les informations d'identification temporaires sous forme de signatures aux API demandes correspondant aux informations requises Services AWS.

  18. IAMévalue les politiques associées au rôle dans les informations d'identification. Il les compare à la demande.

  19. Service AWS Renvoie les données demandées.

  20. L'application affiche les données dans l'interface utilisateur.

  21. L'utilisateur consulte les données.

Variantes et personnalisation

Pour visualiser l'authentification auprès d'un groupe d'utilisateurs, insérez l'un des aperçus précédents du groupe d'utilisateurs après l'étape Émettre un jeton/une assertion. L'authentification du développeur remplace toutes les étapes précédant la demande d'identité par une demande signée par les informations d'identification du développeur. L'authentification des invités passe également directement à Request identity, ne valide pas l'authentification et renvoie les informations d'identification pour un rôle à accès limitéIAM.

Ressources connexes