Flux d'authentification de groupes d'identités (identités fédérées)

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 Rôles IAM.

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

Lorsque vous utilisez le flux d'authentification amélioré, votre application présente d'abord un identifiant ou un jeton d'accès provenant d'un groupe d'utilisateurs Amazon Cognito autorisé ou d'un fournisseur d'identité tiers dans GetIdune demande. L'application échange le jeton contre un identifiant d'identité dans votre groupe d'identités. L'ID d'identité est ensuite utilisé avec le même jeton de fournisseur d'identité dans une demande GetCredentialsForIdentity. Le flux de travail amélioré simplifie la récupération des informations d'identification en effectuant des tâches GetOpenIdTokenet AssumeRoleWithWebIdentityen arrière-plan pour vous. GetCredentialsForIdentityrenvoie les informations d'identification de l' AWS API qui autorisent vos utilisateurs à accéder aux AWS ressources pendant une heure.

1. GetId

2. GetCredentialsForIdentity

Flux d'authentification basique (classique)

Lorsque vous utilisez le flux d'authentification de base, votre application présente d'abord un jeton d'identification provenant d'un groupe d'utilisateurs Amazon Cognito autorisé ou d'un fournisseur d'identité tiers dans une demande GetID. L'application échange le jeton contre un identifiant d'identité dans votre groupe d'identités. L'ID d'identité est ensuite utilisé avec le même jeton de fournisseur d'identité dans une demande GetOpenIdToken. GetOpenIdToken renvoie un nouveau jeton OAuth 2.0 émis par votre groupe d'identités. Vous pouvez ensuite utiliser le nouveau jeton dans une AssumeRoleWithWebIdentitydemande pour récupérer les informations d'identification de AWS l'API. 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.

1. GetId

2. GetOpenIdToken

3. AssumeRoleWithWebIdentity

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

Lors de l'utilisation de Identités authentifiées par le développeur (réserves d'identités), 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é

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

Flux d'authentification basique

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. AssumeRoleWithWebIdentity

Quel flux d'authentification utiliser ?

Le flux amélioré convient à la plupart des clients, car il offre plusieurs avantages par rapport au flux basique :

• Un appel réseau de moins pour obtenir les informations d'identification de l'appareil

• Tous les appels étant adressés à Amazon Cognito, vous faites l'économie d'une connexion réseau.

• Les rôles n'ont plus besoin d'être intégrés dans votre application. Seuls la région et l'ID du groupe d'identités sont nécessaires pour lancer l'amorçage des informations d'identification.

Depuis février 2015, la console Amazon Cognito affiche un exemple de code qui utilise le flux amélioré. En outre, si votre groupe d'identités n'a pas l'association de rôles nécessaire pour utiliser le flux amélioré, la console affiche une notification.

Les kits suivants sont les versions SDK minimales compatibles avec le flux amélioré :

Kit SDK (version minimale)

• AWS SDK pour iOS (2.0.14)

• AWS SDK pour Android (2.1.8)

• AWS SDK pour JavaScript (2.1.7)

• AWS SDK pour Unity (1.0.3)

• AWS SDK pour Xamarin (3.0.0.5)

Si vous souhaitez utiliser plus que les deux rôles par défaut configurés lorsque vous créez un nouveau groupe d'identités dans la console, utilisez le flux élémentaire.

Récapitulatif API

GetId

L'appel de l'API GetId est le premier appel requis pour établir une nouvelle identité dans Amazon Cognito.

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 groupe d'identités, les utilisateurs peuvent à tout moment demander un nouvel ID d'identité via l'API GetId. L'application est censée mettre en cache cet ID d'identité pour effectuer les appels suivants à Amazon Cognito. Les SDK AWS mobiles et le AWS SDK pour 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 pour un fournisseur de connexion public (Facebook, Google+, Login with Amazon ou Se connecter avec Apple), les utilisateurs sont également en mesure de fournir des jetons (OAuth ou OpenID Connect) qui les identifient auprès de 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

L'API GetCredentialsForIdentity peut être appelée après l'établissement d'un ID d'identité. D'un point de vue fonctionnel, cette API revient à appeler GetOpenIdToken suivi par AssumeRoleWithWebIdentity.

Pour qu'Amazon Cognito appelle AssumeRoleWithWebIdentity en votre nom, des rôles IAM doivent être associés à votre groupe d'identités. Pour ce faire, utilisez la console Amazon Cognito ou procédez manuellement via l'opération SetIdentityPoolRoles.

GetOpenIdToken

Effectuez une demande d'API GetOpenIdToken après avoir établi un ID d'identité. Mettez en cache les identifiants d'identité après votre première demande et démarrez les sessions de base (classiques) suivantes pour cette identité avec GetOpenIdToken.

La réponse à une demande d'API GetOpenIdToken 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, vérifiez-le dans votre application. Vous pouvez utiliser les bibliothèques OIDC de votre kit SDK ou une bibliothèque comme aws-jwt-verify pour confirmer qu'Amazon Cognito a émis le jeton. L'ID de clé de signature, ou kid, du jeton OpenID 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.

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. Puis, une identité devient le parent/propriétaire de toutes les connexions associées, tandis que l'autre est désactivée. Dans ce cas, l'ID d'identité du propriétaire/parent est renvoyée. Vous devez mettre à jour votre cache local si cette valeur diffère. Les fournisseurs des SDK AWS mobiles ou du AWS SDK du navigateur exécutent cette opération pour vous. JavaScript

GetOpenIdTokenForDeveloperIdentity

L'API GetOpenIdTokenForDeveloperIdentity remplace l'utilisation de GetId et GetOpenIdToken à partir de l'appareil en cas d'utilisation d'identités authentifiées par le développeur. Comme cet appel d'API est signé par vos AWS informations d'identification, Amazon Cognito peut être sûr que l'identifiant utilisateur fourni dans l'appel d'API est valide. Cette approche remplace la validation de jeton qu'Amazon Cognito effectue auprès de fournisseurs externes.

La charge utile pour cette API inclut un mappage de connexions qui doit contenir la clé de votre fournisseur de développement et une valeur comme identifiant pour l'utilisateur dans 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 les identifiants d'identité de développeur après votre première demande et démarrez les sessions de base (classiques) suivantes pour cette identité avec GetOpenIdTokenForDeveloperIdentity.

La réponse à une demande d'API GetOpenIdTokenForDeveloperIdentity 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 les bibliothèques OIDC de votre kit SDK ou une bibliothèque comme aws-jwt-verify pour 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

Avec les identités authentifiées par le développeur, Amazon Cognito prend en charge à la fois la fusion implicite et la fusion explicite via l'API MergeDeveloperIdentities. 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 l'appel d'AssumeRoleWithWebIdentityAPI AWS Security Token Service (STS). Cet appel équivaut à utiliser directement Facebook, Google+, Login with Amazon ou Se connecter avec Apple. La seule exception est que vous transmettez un jeton Amazon Cognito à la place d'un jeton provenant de l'un des autres fournisseurs publics.

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 des rôles différents pour votre application : un pour les utilisateurs non authentifiés et un autre pour les utilisateurs authentifiés. La console Amazon Cognito crée ces rôles par défaut pour vous la première fois que vous configurez votre groupe d'identités. La stratégie d'accès pour ces deux rôles est exactement la même : elle autorise les utilisateurs à accéder à Amazon Cognito Sync et ils peuvent soumettre des événements à Amazon Mobile Analytics. Vous pouvez modifier ces rôles pour répondre à 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-West)	https://cognito-identity. us-gov-west-1.amazonaws.com/.well-known/jwks_uri
China (Beijing)	https://cognito-identity.cn-north-1.amazonaws.com.cn/.well-known/jwks_uri
Opt-in Regions like Europe (Milan) and Africa (Cape Town)	https://cognito-identity.Région.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 standard OIDC <issuer>/.well-known/openid-configuration répertorie un chemin d'accès vers le document jwks_uri pour votre jeton.