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.
Configuration d'un domaine de groupe d'utilisateurs
La configuration d'un domaine est facultative lors de la configuration d'un groupe d'utilisateurs. Un domaine de pool d'utilisateurs héberge des fonctionnalités pour l'authentification des utilisateurs, la fédération avec des fournisseurs tiers et les flux OpenID Connect (OIDC). Il possède l'interface utilisateur hébergée, une interface prédéfinie pour les opérations clés telles que l'inscription, la connexion et la récupération du mot de passe. Il héberge également les points de terminaison OpenID Connect (OIDC) standard tels que authorize, et token userInfo, pour l'autorisation machine-to-machine (M2M) et d'autres flux d'authentification OIDC et d'autorisation OAuth 2.0.
Les utilisateurs se connectent à l'interface utilisateur hébergée sur le domaine associé à votre groupe d'utilisateurs. Deux options s'offrent à vous pour configurer ce domaine : vous pouvez soit utiliser le domaine hébergé Amazon Cognito par défaut, soit configurer un domaine personnalisé dont vous êtes le propriétaire.
L'option de domaine personnalisé offre davantage d'options de flexibilité, de sécurité et de contrôle. Par exemple, un domaine familier appartenant à une organisation peut encourager la confiance des utilisateurs et rendre le processus de connexion plus intuitif. Cependant, l'approche du domaine personnalisé nécessite des frais supplémentaires, tels que la gestion du SSL certificat et de la DNS configuration.
Les points de terminaison de OIDC découverte, /.well-known/openid-configuration
pour les points de terminaison URLs et /.well-known/jwks.json
pour les clés de signature de jetons, ne sont pas hébergés sur votre domaine. Pour de plus amples informations, veuillez consulter Points de terminaison du fournisseur d'identité et des parties utilisatrices.
Comprendre comment configurer et gérer le domaine de votre groupe d'utilisateurs Amazon Cognito est une étape importante pour intégrer l'authentification dans votre application. Connectez-vous aux groupes d'utilisateurs API et cela AWS SDK peut être une alternative à la configuration d'un domaine. Le modèle API basé fournit des jetons directement dans une API réponse, mais pour les implémentations qui utilisent les fonctionnalités étendues des groupes d'utilisateurs en tant qu'OIDCIdP, vous devez configurer un domaine. Pour plus d'informations sur les modèles d'authentification disponibles dans les groupes d'utilisateurs, consultezUtilisation des groupes d'utilisateurs API et du serveur d'autorisation.
Rubriques
Ce qu'il faut savoir sur les domaines du pool d'utilisateurs
Les domaines du pool d'utilisateurs constituent un point de service pour les parties OIDC dépendantes de vos applications et pour les éléments de l'interface utilisateur. Tenez compte des détails suivants lorsque vous planifiez la mise en œuvre d'un domaine pour votre groupe d'utilisateurs.
Termes réservés
Vous ne pouvez pas utiliser le texte aws
ou amazon
cognito
le nom d'un domaine de préfixe Amazon Cognito.
Les points de terminaison de découverte se trouvent dans un domaine différent
Les points de terminaison de découverte du groupe .well-known/openid-configuration
d'utilisateurs .well-known/jwks.json
ne se trouvent pas sur le domaine personnalisé ou préfixe de votre groupe d'utilisateurs. Le chemin d'accès à ces points de terminaison est le suivant.
-
https://cognito-idp.
Region
.amazonaws.com/your user pool ID
/.well-known/openid-configuration -
https://cognito-idp.
Region
.amazonaws.com/your user pool ID
/.well-known/jwks.json
Domaines personnalisés et préfixes à la fois
Vous pouvez configurer un groupe d'utilisateurs avec à la fois un domaine personnalisé et un domaine préfixe appartenant AWSà. Les points de terminaison de découverte du groupe d'utilisateurs étant hébergés dans un domaine différent, ils ne desservent que le domaine personnalisé. Par exemple, vous openid-configuration
fournirez une valeur unique pour "authorization_endpoint"
of"https://auth.example.com/oauth2/authorize"
.
Lorsque vous avez à la fois des domaines personnalisés et des domaines préfixes dans un groupe d'utilisateurs, vous pouvez utiliser le domaine personnalisé avec toutes les fonctionnalités d'un OIDC fournisseur. Le domaine de préfixe d'un groupe d'utilisateurs avec cette configuration n'a pas de découverte ni de token-signing-key point de terminaison et doit être utilisé en conséquence.
N'utilisez pas de domaines personnalisés à différents niveaux de votre hiérarchie de domaines
Vous pouvez configurer des groupes d'utilisateurs distincts pour avoir des domaines personnalisés dans le même domaine de premier niveau (TLD), par exemple auth.example.com et auth2.example.com. Le cookie de session d'interface utilisateur hébergé est valide pour un domaine personnalisé et tous les sous-domaines, par exemple *.auth.example.com. De ce fait, aucun utilisateur de vos applications ne doit accéder à l'interface utilisateur hébergée pour un domaine ou un sous-domaine parent. Lorsque des domaines personnalisés utilisent la même solutionTLD, conservez-les au même niveau de sous-domaine.
Supposons que vous ayez un groupe d'utilisateurs avec le domaine personnalisé auth.example.com. Vous créez ensuite un autre groupe d'utilisateurs et attribuez le domaine personnalisé uk.auth.example.com. . Un utilisateur se connecte avec auth.example.com. et obtient un cookie que son navigateur présente à *.auth.example.com. Ils essaient ensuite de se connecter à uk.auth.example.com. . Ils transmettent un cookie non valide à l'interface utilisateur hébergée et reçoivent une erreur au lieu d'une invite de connexion. En revanche, un utilisateur possédant un cookie pour *.auth.example.com n'a aucun problème à démarrer une session de connexion sur auth2.example.com.