Flux d'authentification des groupes d'identités - Amazon Cognito

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.

Flux d'authentification des groupes d'identités

Amazon Cognito vous aide à créer des identifiants uniques que vos utilisateurs finaux peuvent utiliser sur divers appareils et plateformes. Amazon Cognito fournit également des informations d'identification temporaires à privilèges limités à votre application pour accéder aux ressources. AWS Cette page présente les principes de base de l'authentification dans Amazon Cognito, et explique le cycle de vie d'une identité au sein d'un groupe d'identités.

Flux d'authentification avec fournisseurs externes

Un utilisateur s'authentifiant avec Amazon Cognito suit un processus en plusieurs étapes pour amorcer ses informations d'identification. Amazon Cognito propose deux flux d'authentification distincts auprès de fournisseurs publics : le flux de base et le flux amélioré.

Une fois que vous avez terminé l'un de ces flux, vous pouvez accéder Services AWS aux autres conformément aux politiques d'accès de votre rôle. Par défaut, la console Amazon Cognito crée des rôles ayant accès au magasin Amazon Cognito Sync et à Amazon Mobile Analytics. Pour plus d'informations sur la façon d'octroyer des accès supplémentaires, consultez IAMrôles.

Les pools d'identités acceptent les artefacts suivants provenant des fournisseurs :

Fournisseur Artefact d'authentification
Groupe d’utilisateurs Amazon Cognito Jeton d’identification
OpenID Connect () OIDC Jeton d’identification
SAML2,0 SAMLassertion
Prestataire social Jeton d’accès

Flux d'authentification amélioré (simplifié)

Lorsque vous utilisez le flux d'authentification amélioré, votre application présente d'abord une preuve d'authentification provenant d'un groupe d'utilisateurs Amazon Cognito autorisé ou d'un fournisseur d'identité tiers dans GetIdune demande.

  1. Votre application présente une preuve d'authentification (jeton JSON Web ou SAML assertion) provenant d'un groupe d'utilisateurs Amazon Cognito autorisé ou d'un fournisseur d'identité tiers dans une demande GetID.

  2. Votre pool d'identités renvoie un identifiant d'identité.

  3. Votre application associe l'identifiant d'identité à la même preuve d'authentification dans une GetCredentialsForIdentitydemande.

  4. Votre pool d'identités renvoie les AWS informations d'identification.

  5. Votre application signe les AWS API demandes avec les informations d'identification temporaires.

L'authentification améliorée gère la logique de sélection des IAM rôles et de récupération des informations d'identification dans la configuration de votre pool d'identités. Vous pouvez configurer votre pool d'identités pour sélectionner un rôle par défaut, pour appliquer les principes du contrôle d'accès basé sur les attributs (ABAC) ou du contrôle d'accès basé sur les rôles (RBAC) à la sélection des rôles. Les AWS informations d'identification issues de l'authentification améliorée sont valides pendant une heure.

Ordre des opérations dans l'authentification améliorée

  1. GetId

  2. GetCredentialsForIdentity

Schéma illustrant le déroulement de l'authentification améliorée

Flux d'authentification basique (classique)

Lorsque vous utilisez le flux d'authentification de base,

  1. Votre application présente une preuve d'authentification (jeton JSON Web ou SAML assertion) provenant d'un groupe d'utilisateurs Amazon Cognito autorisé ou d'un fournisseur d'identité tiers dans une demande GetID.

  2. Votre pool d'identités renvoie un identifiant d'identité.

  3. Votre application associe l'identifiant d'identité à la même preuve d'authentification dans une GetOpenIdTokendemande.

  4. GetOpenIdTokenrenvoie un nouveau jeton OAuth 2.0 émis par votre pool d'identités.

  5. Votre application présente le nouveau jeton dans une AssumeRoleWithWebIdentitydemande.

  6. AWS Security Token Service AWS STS) renvoie les AWS informations d'identification.

  7. Votre application signe les AWS API demandes avec les informations d'identification temporaires.

Le flux de travail de base vous offre un contrôle plus précis sur les informations d'identification que vous distribuez à vos utilisateurs. La demande GetCredentialsForIdentity du flux d'authentification amélioré demande un rôle basé sur le contenu d'un jeton d'accès. La AssumeRoleWithWebIdentity demande dans le flux de travail classique donne à votre application une plus grande capacité à demander des informations d'identification pour tout AWS Identity and Access Management rôle que vous avez configuré avec une politique de confiance suffisante. Vous pouvez également demander une durée de session de rôle personnalisée.

Vous pouvez vous connecter avec le flux d'authentification de base dans les groupes d'utilisateurs qui ne disposent pas de mappage de rôles. Ce type de pool d'identités ne possède pas de rôle authentifié ou non authentifié par défaut, et aucun contrôle d'accès basé sur les rôles ou les attributs n'est configuré. Lorsque vous essayez d'accéder GetOpenIdToken à un pool d'identités avec des mappages de rôles, le message d'erreur suivant s'affiche.

Basic (classic) flow is not supported with RoleMappings, please use enhanced flow.
Ordre des opérations dans l'authentification de base

  1. GetId

  2. GetOpenIdToken

  3. AssumeRoleWithWebIdentity

Schéma illustrant le déroulement de l'authentification de base

Flux d'authentification des identités par les développeurs

Lors de l'utilisation de Identités authentifiées par le développeur, le client utilise un autre flux d'authentification incluant du code en dehors d'Amazon Cognito afin de valider l'utilisateur dans votre propre système d'authentification. Le code en dehors d'Amazon Cognito est indiqué tel quel.

Flux d'authentification amélioré

Ordre des opérations dans l'authentification améliorée auprès d'un fournisseur de développement

  1. Se connecter via un fournisseur de développement (code en dehors d'Amazon Cognito)

  2. Valider la connexion de l'utilisateur (code en dehors d'Amazon Cognito)

  3. GetOpenIdTokenForDeveloperIdentity

  4. GetCredentialsForIdentity

Schéma illustrant le flux de l'authentification améliorée authentifiée par le développeur
Ordre des opérations dans l'authentification de base auprès d'un fournisseur de développement

  1. Implémentez une logique en dehors du pool d'identités pour vous connecter et générer un identifiant développeur-fournisseur.

  2. Récupérez les informations d'identification stockées côté serveur. AWS

  3. Envoyez l'identifiant du fournisseur développeur dans une GetOpenIdTokenForDeveloperIdentityAPIdemande signée avec des AWS informations d'identification autorisées.

  4. Demandez les informations d'identification de l'application auprès de AssumeRoleWithWebIdentity.

Schéma illustrant le flux de l'authentification de base authentifiée par le développeur

Quel flux d'authentification utiliser ?

Le flux amélioré est le choix le plus sûr qui demande le moins d'efforts aux développeurs :

  • Le flux amélioré réduit la complexité, la taille et le taux des API demandes.

  • Votre application n'a pas besoin de faire de API demandes supplémentaires auprès de AWS STS.

  • Votre pool d'identités évalue vos utilisateurs en fonction des informations d'identification de IAM rôle qu'ils devraient recevoir. Vous n'avez pas besoin d'intégrer la logique de sélection des rôles dans votre client.

Important

Lorsque vous créez un nouveau pool d'identités, il est recommandé de ne pas activer l'authentification de base (classique) par défaut. Pour implémenter l'authentification de base, évaluez d'abord les relations de confiance de vos IAM rôles pour les identités Web. Intégrez ensuite la logique de sélection des rôles dans votre client et protégez le client contre toute modification par les utilisateurs.

Le flux d'authentification de base délègue la logique de sélection des IAM rôles à votre application. Dans ce flux, Amazon Cognito valide la session authentifiée ou non authentifiée de votre utilisateur et émet un jeton que vous pouvez échanger contre des informations d'identification. AWS STS Les utilisateurs peuvent échanger les jetons issus de l'authentification de base contre tous les IAM rôles qui font confiance à votre pool d'identités et/ou à votre amr état authentifié/non authentifié.

De même, sachez que l'authentification des développeurs est un raccourci permettant de valider l'authentification du fournisseur d'identité. Amazon Cognito fait confiance aux AWS informations d'identification qui autorisent une GetOpenIdTokenForDeveloperIdentitydemande sans validation supplémentaire du contenu de la demande. Sécurisez les secrets qui autorisent les développeurs à s'authentifier pour empêcher les utilisateurs d'y accéder.

APIrésumé

GetId

Il s'agit du premier appel nécessaire pour établir une nouvelle identité dans Amazon Cognito. GetIdAPI

Accès non authentifié

Amazon Cognito peut accorder un accès invité non authentifié dans vos applications. Si cette fonctionnalité est activée dans votre pool d'identités, les utilisateurs peuvent demander un nouvel identifiant d'identité à tout moment via le GetIdAPI. L'application est censée mettre en cache cet ID d'identité pour effectuer les appels suivants à Amazon Cognito. The AWS Mobile SDKs et le AWS SDK for JavaScript in the Browser disposent de fournisseurs d'informations d'identification qui gèrent cette mise en cache pour vous.

Accès authentifié

Lorsque vous avez configuré votre application avec la prise en charge d'un fournisseur de connexion public (Facebook, Google+, Login with Amazon ou Sign in with Apple), les utilisateurs peuvent également fournir des jetons (OAuthou OpenID Connect) qui les identifient chez ces fournisseurs. Utilisé dans un appel à GetId, Amazon Cognito crée une nouvelle identité authentifiée ou renvoie l'identité déjà associée à cette connexion spécifique. Amazon Cognito fait cela en validant le jeton auprès du fournisseur et en s'assurant que :

  • Le jeton est valide et provient du fournisseur configuré.

  • Le jeton n'a pas expiré.

  • Le jeton correspond à l'identificateur d'application créé avec ce fournisseur (par exemple, ID d'application Facebook).

  • Le jeton correspond à l'identifiant de l'utilisateur.

GetCredentialsForIdentity

Ils GetCredentialsForIdentityAPIpeuvent être appelés après avoir établi un identifiant d'identité. Cette opération est donc AssumeRoleWithWebIdentityfonctionnellement équivalente à un appel GetOpenIdToken.

Pour qu'Amazon Cognito puisse appeler AssumeRoleWithWebIdentity en votre nom, des IAM rôles doivent être associés à votre pool d'identités. Vous pouvez le faire via la console Amazon Cognito ou manuellement via l'SetIdentityPoolRolesopération.

GetOpenIdToken

Faites une GetOpenIdTokenAPIdemande après avoir établi un identifiant d'identité. Mettez en cache l'identité IDs après votre première demande et lancez les sessions de base (classiques) suivantes pour cette identité avecGetOpenIdToken.

La réponse à une GetOpenIdToken API demande est un jeton généré par Amazon Cognito. Vous pouvez soumettre ce jeton en tant que WebIdentityToken paramètre d'une AssumeRoleWithWebIdentitydemande.

Avant de soumettre le jeton OpenID, vérifiez-le dans votre application. Vous pouvez utiliser OIDC des bibliothèques dans votre bibliothèque SDK ou une bibliothèque comme aws-jwt-verifypour confirmer qu'Amazon Cognito a émis le jeton. L'identifiant de la clé de signature, oukid, du jeton OpenID est l'un de ceux répertoriés dans Amazon Cognito Identity jwks_uri document †. Ces clés sont susceptibles d'être modifiées. Votre fonction qui vérifie les jetons d'identité Amazon Cognito doit régulièrement mettre à jour sa liste de clés à partir du document jwks_uri. Amazon Cognito définit la durée d'actualisation dans l'en-tête de réponse cache-control de jwks_uri, actuellement définie avec un paramètre max-age de 30 jours.

Accès non authentifié

Pour obtenir un jeton pour une identité non authentifiée, vous avez uniquement besoin de l'ID d'identité. Il n'est pas possible d'obtenir un jeton non authentifié pour les identités authentifiées ou les identités que vous avez désactivées.

Accès authentifié

Si vous avez une identité authentifiée, vous devez transmettre au moins un jeton valide pour une connexion déjà associée à cette identité. Tous les jetons transmis au cours de l'appel GetOpenIdToken doivent passer par le processus de validation mentionné ci-dessus. Si un jeton échoue, l'appel n'aboutit pas. La réponse à l'appel GetOpenIdToken inclut également l'ID d'identité, car l'ID d'identité que vous fournissez n'est pas toujours celui qui est renvoyé.

Liaison de connexions

Si vous soumettez un jeton pour une connexion qui n'est pas déjà associée à une identité, la connexion est considéré comme étant « liée » à l'identité associée. Vous ne pouvez lier qu'une connexion par fournisseur public. Toute tentative de liaison de plusieurs connexions avec un fournisseur public entraîne une réponse d'erreur ResourceConflictException. Si une connexion est simplement liée à une identité existante, l'ID d'identité renvoyé à partir de GetOpenIdToken est la même que celle que vous avez transmise.

Fusion d'identités

Si vous transmettez un jeton pour une connexion qui n'est pas liée à l'identité donnée, mais qui est liée à une autre identité, les deux identités sont fusionnées. Une fois fusionnée, une identité devient celle qui parent/owner of all associated logins and the other is disabled. In this case, the identity ID of the parent/owner est renvoyée. Vous devez mettre à jour votre cache local si cette valeur diffère. Les fournisseurs du AWS mobile SDKs ou AWS SDK JavaScript du navigateur effectuent cette opération pour vous.

GetOpenIdTokenForDeveloperIdentity

L'GetOpenIdTokenForDeveloperIdentityopération remplace l'utilisation de GetIdet GetOpenIdTokendepuis l'appareil lors de l'utilisation d'identités authentifiées par le développeur. Dans la mesure où votre application signe les demandes relatives à cette API opération avec des AWS informations d'identification, Amazon Cognito s'assure que l'identifiant utilisateur fourni dans la demande est valide. L'authentification du développeur remplace la validation par jeton effectuée par Amazon Cognito auprès de fournisseurs externes.

La charge utile correspondante API inclut une logins carte. Cette carte doit contenir la clé de votre fournisseur de développement et une valeur servant d'identifiant pour l'utilisateur de votre système. Si l'identifiant de l'utilisateur n'est pas encore lié à une identité existante, Amazon Cognito crée une nouvelle identité et renvoie le nouvel ID d'identité ainsi qu'un jeton OpenID Connect pour cette identité. Si l'identifiant de l'utilisateur est déjà lié, Amazon Cognito renvoie l'ID d'identité préexistant et un jeton OpenID Connect. Mettez en cache l'identité du développeur IDs après votre première demande et lancez les sessions de base (classiques) suivantes pour cette identité avecGetOpenIdTokenForDeveloperIdentity.

La réponse à une GetOpenIdTokenForDeveloperIdentity API demande est un jeton généré par Amazon Cognito. Vous pouvez soumettre ce jeton en tant que paramètre WebIdentityToken dans une demande AssumeRoleWithWebIdentity.

Avant de soumettre le jeton OpenID Connect, vérifiez-le dans votre application. Vous pouvez utiliser OIDC des bibliothèques dans votre bibliothèque SDK ou une bibliothèque comme aws-jwt-verifypour confirmer qu'Amazon Cognito a émis le jeton. L'ID de clé de signature, ou kid, du jeton OpenID Connect est l'un de ceux répertoriés dans le document jwks_uri d'identité Amazon Cognito†. Ces clés sont susceptibles d'être modifiées. Votre fonction qui vérifie les jetons d'identité Amazon Cognito doit régulièrement mettre à jour sa liste de clés à partir du document jwks_uri. Amazon Cognito définit la durée d'actualisation dans l'en-tête de réponse cache-control de jwks_uri, actuellement définie avec un paramètre max-age de 30 jours.

Liaison de connexions

Comme avec les fournisseurs externes, fournir des connexions supplémentaires qui ne sont pas encore associées à une identité entraîne implicitement la liaison de ces connexions à cette identité. Si vous liez une connexion de fournisseur externe à une identité, l'utilisateur peut utiliser le flux d'authentification du fournisseur externe avec ce fournisseur. Toutefois, il ne peut pas utiliser le nom de votre fournisseur de développement dans la carte des connexions lorsqu'il appelle GetId ou GetOpenIdToken.

Fusion d'identités

Grâce aux identités authentifiées par les développeurs, Amazon Cognito prend en charge à la fois la fusion implicite et la fusion explicite via le. MergeDeveloperIdentitiesAPI La fusion explicite vous permet de marquer deux identités avec des identifiants utilisateur dans votre système comme une seule identité. Si vous fournissez les identifiants utilisateur source et de destination, Amazon Cognito les fusionne. La prochaine fois que vous demandez un jeton OpenID Connect pour l'un de ces identifiants utilisateur, le même ID d'identité est renvoyé.

AssumeRoleWithWebIdentity

Une fois que vous avez un jeton OpenID Connect, vous pouvez l'échanger contre des informations d' AWS identification temporaires via la AssumeRoleWithWebIdentityAPIdemande adressée à AWS Security Token Service ()AWS STS.

Comme il n'y a aucune restriction sur le nombre d'identités que vous pouvez créer, il est important de comprendre les autorisations que vous accordez à vos utilisateurs. Configurez différents IAM rôles pour votre application : un pour les utilisateurs non authentifiés et un pour les utilisateurs authentifiés. La console Amazon Cognito peut créer des rôles par défaut lorsque vous configurez votre pool d'identités pour la première fois. Aucune autorisation n'est effectivement accordée à ces rôles. Modifiez-les en fonction de vos besoins.

En savoir plus sur Autorisations et approbation de rôle.

† Le document jwks_uri d'identité Amazon Cognito par défaut contient des informations sur les clés utilisées pour signer les jetons pour les groupes d'identités dans la plupart des Régions AWS. Les régions suivantes ont des documents jwks_uri différents.

Amazon Cognito Identity JSON web key URIs in other Régions AWS
Région AWS Chemin d'accès au document jwks_uri
AWS GovCloud (US-Ouest) https://cognito-identity.us-gov-west-1.amazonaws.com/.well-known/jwks_uri
Chine (Beijing) https://cognito-identity---cn-north-1.amazonaws.com.rproxy.goskope.com.cn/.well-known/jwks_uri
Régions optionnelles comme l'Europe (Milan) et l'Afrique (Le Cap) https://cognito-identity.Region.amazonaws.com/.well-known/jwks_uri

Vous pouvez également extrapoler le document jwks_uri provenant de l'émetteur, ou iss, que vous recevez dans le jeton OpenID provenant d'Amazon Cognito. Le point de terminaison de découverte OIDC -standard <issuer>/.well-known/openid-configuration répertorie un chemin vers le jwks_uri de votre jeton.