As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Como configurar um domínio de grupo de usuários

Configurar um domínio é uma parte opcional da configuração de um grupo de usuários. Um domínio de grupo de usuários hospeda recursos para autenticação de usuários, federação com provedores terceirizados e fluxos do OpenID Connect (OIDC). Ele tem a interface de usuário hospedada, uma interface pré-criada para operações importantes, como inscrição, login e recuperação de senha. Ele também hospeda os endpoints padrão do OpenID Connect (OIDC), como authorize e token userInfo, para autorização machine-to-machine (M2M) e outros OIDC fluxos de autenticação e autorização 2.0. OAuth

Os usuários fazem login na interface de usuário hospedada no domínio associado ao seu grupo de usuários. Você tem duas opções para configurar esse domínio: você pode usar o domínio hospedado padrão do Amazon Cognito ou configurar um domínio personalizado de sua propriedade.

A opção de domínio personalizado tem mais opções de flexibilidade, segurança e controle. Por exemplo, um domínio familiar de propriedade da organização pode incentivar a confiança do usuário e tornar o processo de login mais intuitivo. No entanto, a abordagem de domínio personalizado exige alguma sobrecarga adicional, como gerenciar o SSL certificado e a DNS configuração.

Os endpoints de OIDC descoberta, /.well-known/openid-configuration para endpoints URLs e /.well-known/jwks.json chaves de assinatura de token, não estão hospedados em seu domínio. Para obter mais informações, consulte Provedor de identidade e endpoints de terceiros confiáveis.

Entender como configurar e gerenciar o domínio para seu grupo de usuários do Amazon Cognito é uma etapa importante na integração da autenticação em seu aplicativo. Faça login com os grupos de usuários API e um AWS SDK pode ser uma alternativa à configuração de um domínio. O modelo API baseado fornece tokens diretamente em uma API resposta, mas para implementações que usam os recursos estendidos dos grupos de usuários como um OIDC IdP, você deve configurar um domínio. Para obter mais informações sobre os modelos de autenticação que estão disponíveis nos grupos de usuários, consulteUsando os grupos de usuários API e o servidor de autorização.

Coisas que você deve saber sobre domínios de grupos de usuários

Os domínios do grupo de usuários são um ponto de serviço para pessoas que OIDC confiam em seus aplicativos e para elementos de interface do usuário. Considere os detalhes a seguir ao planejar a implementação de um domínio para seu grupo de usuários.

Termos reservados

Você não pode usar o textoaws,amazon, ou cognito no nome de um domínio com prefixo do Amazon Cognito.

Os endpoints do Discovery estão em um domínio diferente

O grupo de usuários descobre endpoints .well-known/openid-configuration e .well-known/jwks.json não está no domínio personalizado ou de prefixo do grupo de usuários. O caminho para esses endpoints é o seguinte.

Domínios personalizados e prefixos ao mesmo tempo

Você pode configurar um grupo de usuários com um domínio personalizado e um domínio de prefixo de propriedade AWS da. Como os endpoints de descoberta do grupo de usuários estão hospedados em um domínio diferente, eles servem apenas ao domínio personalizado. Por exemplo, você openid-configuration fornecerá um valor único para "authorization_endpoint" de"https://auth.example.com/oauth2/authorize".

Quando você tem domínios personalizados e prefixos em um grupo de usuários, você pode usar o domínio personalizado com todos os recursos de um OIDC provedor. O domínio de prefixo em um grupo de usuários com essa configuração não tem descoberta nem token-signing-key endpoints e deve ser usado adequadamente.

Não use domínios personalizados em diferentes níveis da sua hierarquia de domínios

Você pode configurar grupos de usuários separados para ter domínios personalizados no mesmo domínio de primeiro nível (TLD), por exemplo auth.example.com e auth2.example.com. O cookie de sessão de interface de usuário hospedada é válido para um domínio personalizado e todos os subdomínios, por exemplo, *.auth.example.com. Por esse motivo, nenhum usuário de seus aplicativos deve acessar a interface de usuário hospedada de qualquer domínio ou subdomínio principal. Quando os domínios personalizados usam o mesmoTLD, mantenha-os no mesmo nível de subdomínio.

Digamos que você tenha um grupo de usuários com o domínio personalizado auth.example.com. Em seguida, você cria outro grupo de usuários e atribui o domínio personalizado uk.auth.example.com. . Um usuário faz login com auth.example.com. e recebe um cookie que seu navegador apresenta para *.auth.example.com. Em seguida, eles tentam fazer login em uk.auth.example.com. . Eles passam um cookie inválido para a interface hospedada e recebem um erro em vez de uma solicitação de login. Por outro lado, um usuário com um cookie para *.auth.example.com não tem problemas em iniciar uma sessão de login em auth2.example.com.