Referência do provedor de método externo de autenticação multifator do Microsoft Entra (versão prévia)
Este tópico descreve como um provedor de autenticação externa se conecta à autenticação multifator (MFA) do Microsoft Entra. Um provedor de autenticação externa pode se integrar aos locatários do Microsoft Entra ID como um método de autenticação externa (EAM). Um EAM pode cumprir o segundo fator de um requisito de MFA para acesso a um recurso ou aplicação. Os EAMs exigem pelo menos uma licença do Microsoft Entra ID P1.
Quando um usuário entra, essas políticas de locatário são avaliadas. Os requisitos de autenticação são determinados com base no recurso que o usuário tenta acessar.
Várias políticas podem ser aplicadas à entrada, dependendo de seus parâmetros. Esses parâmetros incluem usuários e grupos, aplicativos, plataforma, nível de risco da entrada e muito mais.
Com base nos requisitos de autenticação, talvez o usuário precise entrar com outro fator para atender ao requisito da MFA. O segundo fator precisa complementar o tipo do primeiro fator.
Os EAMs são adicionados ao Microsoft Entra ID pelo administrador do locatário. Se um locatário exige um EAM para MFA, a entrada é considerada para atender ao requisito de MFA depois que o Microsoft Entra ID validar ambos:
- O primeiro fator concluído com o Microsoft Entra ID
- O segundo fator concluído com o EAM
Essa validação atende ao requisito de MFA para dois ou mais tipos de métodos de:
- Algo que você conhece (conhecimento)
- Algo que você tem (posse)
- Algo que você é (inerência)
Os EAMs são implementados com base no Open ID Connect (OIDC). Essa implementação exige pelo menos três pontos de extremidade voltados para o público:
- Um ponto de extremidade de Descoberta OIDC, conforme descrito em Descoberta de metadados do provedor
- Um ponto de extremidade de autenticação OIDC válido
- Uma URL onde os certificados públicos do provedor são publicados
Vamos analisar mais de perto como a entrada funciona com um EAM:
- Um usuário tenta entrar com um primeiro fator, como uma senha, para um aplicativo protegido pelo Microsoft Entra ID.
- O Microsoft Entra ID determina que outro fator precisa ser satisfeito. Por exemplo, uma política de Acesso Condicional exige MFA.
- O usuário escolhe o EAM como segundo fator.
- O Microsoft Entra ID redireciona a sessão do navegador do usuário para a URL do EAM:
- Essa URL é descoberta a partir da URL de descoberta provisionada pela administração quando criou o EAM.
- O aplicativo fornece um token expirado ou quase expirado que contém informações para identificar o usuário e o locatário.
- O provedor de autenticação externa valida se o token veio do Microsoft Entra ID e verifica o conteúdo do token.
- O provedor de autenticação externa pode, opcionalmente, fazer uma chamada para o Microsoft Graph e buscar informações adicionais sobre o usuário.
- O provedor de autenticação externa realiza todas as ações que considere necessárias, como autenticar o usuário com alguma credencial.
- O provedor de autenticação externa redireciona o usuário de volta ao Microsoft Entra ID com um token válido, incluindo todas as declarações necessárias.
- O Microsoft Entra ID valida que a assinatura do token veio do provedor de autenticação externa configurado e depois verifica o conteúdo do token.
- O Microsoft Entra ID valida o token em relação aos requisitos.
- O usuário atende ao requisito de MFA se a validação for bem-sucedida. O usuário também pode ter que atender a outros requisitos de política.
Configurar um novo provedor de autenticação externa com o Microsoft Entra ID
É necessário um aplicativo que representa a integração para que os EAMs emitam o id_token_hint. O aplicativo pode ser criado de duas maneiras:
- Criado em cada locatário que usa o provedor externo.
- Criado como um aplicativo multilocatário. Os administradores de função com privilégios precisam dar consentimento para habilitar a integração para seu locatário.
Um aplicativo multilocatário reduz a chance de configurações incorretas em cada locatário. Também permite que os provedores façam alterações nos metadados, como URLs de resposta em um só lugar, em vez de exigir que cada locatário faça as mudanças.
Para configurar um aplicativo multilocatário,a administração do provedor deve primeiro:
Criar um locatário do Microsoft Entra ID se eles ainda não tiverem um.
Registrar um aplicativo em seu locatário.
Definir os tipos de conta com suporte do aplicativo para: contas em qualquer diretório organizacional (qualquer locatário do Microsoft Entra ID – multilocatário)
Adicionar a permissão delegada
openideprofiledo Microsoft Graph ao aplicativo.Não publicar nenhum escopo neste aplicativo.
Adicionar as URLs válidas de authorization_endpoint válidas do provedor de identidade externa a esse aplicativo como URLs de Resposta.
Observação
O authorization_endpoint fornecido no documento de descoberta do provedor deve ser adicionado como uma URL de redirecionamento no registro de aplicativo. Caso contrário, o seguinte erro aparecerá: ENTRA IDSTS50161: falha ao validar a URL de autorização do provedor de declarações externas!
O processo de registro de aplicativo cria um aplicativo com várias propriedades. Essas propriedades são necessárias para o nosso cenário.
| Propriedade | Descrição |
|---|---|
| ID de objeto | O provedor pode usar a ID do objeto com o Microsoft Graph para consultar as informações do aplicativo. O provedor pode usar a ID do objeto para recuperar e editar as informações do aplicativo de forma programática. |
| Application ID | O provedor pode usar a ID do aplicativo como a ClientId do aplicativo. |
| URL da home page | A URL da home page do provedor não é usada para nada, mas é exigida como parte do registro do aplicativo. |
| URLs de resposta | URLs de redirecionamento válidas para o provedor. Uma delas deve corresponder à URL do host do provedor que foi definida para o locatário do provedor. Uma das URLs de resposta registradas deve corresponder ao prefixo do authorization_endpoint que o Microsoft Entra ID recupera por meio da descoberta OIDC para a URL do host. |
Um aplicativo para cada locatário também é um modelo válido para dar suporte à integração. Se você usar um registro de locatário único, o administrador do locatário precisa criar um registro de aplicativo com as propriedades na tabela anterior para um aplicativo de locatário único.
Observação
É necessário o consentimento do administrador para o aplicativo no locatário que usa o EAM. Se não houver consentimento, o seguinte erro será exibido quando a administração tentar usar o EAM: AADSTS900491: Entidade de serviço <sua ID do Aplicativo> não encontrada.
Configurar declarações opcionais
Um provedor pode configurar mais declarações usando as declarações opcionais para id_token.
Observação
Independentemente de como o aplicativo é criado, o provedor precisa configurar declarações opcionais para cada ambiente de nuvem. Se um aplicativo multilocatário for usado para o Azure global e o Azure for US Government, cada ambiente de nuvem exigirá um aplicativo e uma ID de aplicativo e diferente.
Adicionar um EAM ao Microsoft Entra ID
As informações do provedor de identidade externa são armazenadas na política de Métodos de autenticação de cada locatário. As informações do provedor são armazenadas como um método de autenticação do tipo externalAuthenticationMethodConfiguration.
Cada provedor tem uma entrada na lista de objetos da política. Cada entrada precisa declarar:
- Se o método está habilitado
- Os grupos incluídos que podem usar o método
- Os grupos excluídos que não podem usar o método
Os Administradores de Acesso Condicional podem criar uma política com a Exigência de Concessão de MFA para definir o requisito de MFA para entrada do usuário. Atualmente, não há suporte para os métodos de autenticação externa com pontos fortes de autenticação.
Para mais informações sobre como adicionar um método de autenticação externa no Centro de administração do Microsoft Entra, confira o tópico Gerenciar um método de autenticação externa no Microsoft Entra ID (versão prévia).
Interação do Microsoft Entra ID com o provedor
As próximas seções explicam os requisitos do provedor e incluem exemplos de interação do Microsoft Entra ID com um provedor.
Descoberta de metadados do provedor
Um provedor de identidade externa precisa fornecer um ponto de extremidade de descoberta OIDC. Esse ponto de extremidade é usado para obter mais dados de configuração. A URL completa, incluindo .well-known/oidc-configuration, deve ser incluída na URL de Descoberta configurada durante a criação do EAM.
O ponto de extremidade retorna um documento JSON de Metadados do Provedor hospedado lá. O ponto de extremidade também deve retornar o cabeçalho content-length válido.
A tabela a seguir lista os dados que devem estar presentes nos metadados do provedor. Esses valores são necessários para esse cenário de extensibilidade. O documento de metadados JSON pode conter mais informações.
Para o documento OIDC com os valores de Metadados do Provedor, confira Metadados do provedor.
| Valor dos metadados | Valor | Comentários |
|---|---|---|
| Emissor | Essa URL deve corresponder tanto à URL do host usada para descoberta quanto à declaração ISS nos tokens emitidos pelo serviço do provedor. | |
| authorization_endpoint | O ponto de extremidade com o qual o Microsoft Entra ID se comunica para autorização. Esse ponto de extremidade deve estar presente como uma das URLs de resposta para os aplicativos permitidos. | |
| jwks_uri | Onde o Microsoft Entra ID pode encontrar as chaves públicas necessárias para verificar as assinaturas emitidas pelo provedor. [!OBSERVAÇÃO] O parâmetro x5c da Chave Web JSON (JWK) deve estar presente para fornecer representações X.509 das chaves fornecidas. |
|
| scopes_supported | openid | Outros valores também podem ser incluídos, mas não são obrigatórios. |
| response_types_supported | id_token | Outros valores também podem ser incluídos, mas não são obrigatórios. |
| subject_types_supported | ||
| id_token_signing_alg_values_supported | A Microsoft oferece suporte ao RS256 | |
| claim_types_supported | normal | Essa propriedade é opcional, mas, se presente, deve incluir o valor normal; outros valores também podem ser incluídos. |
http://customcaserver.azurewebsites.net/v2.0/.well-known/openid-configuration
{
"authorization_endpoint": "https://customcaserver.azurewebsites.net/api/Authorize",
"claims_supported": [
"email"
],
"grant_types_supported": [
"implicit"
],
"id_token_signing_alg_values_supported": [
"RS256"
],
"issuer": "https://customcaserver.azurewebsites.net",
"jwks_uri": "http://customcaserver.azurewebsites.net/.well-known/jwks",
"response_modes_supported": [
"form_post"
],
"response_types_supported": [
"id_token"
],
"scopes_supported": [
"openid"
],
"SigningKeys": [],
"subject_types_supported": [
"public"
]
}
http://customcaserver.azurewebsites.net/.well-known/jwks
{
"keys": [
{
"kty": "RSA",
"use": "sig",
"kid": "A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u",
"x5t": "A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u",
"n": "jq277LRoE6WKM0awT3b...vt8J6MZvmgboVB9S5CMQ",
"e": "AQAB",
"x5c": [
"cZa3jz...Wo0rzA="
]
}
]
}
Observação
O parâmetro x5c da JWK deve estar presente para fornecer representações X.509 das chaves fornecidas.
Cache de metadados do provedor
Para melhorar o desempenho, o Microsoft Entra ID armazena em cache os metadados retornados pelo provedor, incluindo as chaves. O cache de metadados do provedor evita uma chamada de descoberta sempre que o Microsoft Entra ID fala com um provedor de identidade externa.
Esse cache é atualizado a cada 24 horas (um dia). Veja como sugerimos que um provedor substitua as chaves:
- Publique o Certificado Existente e o Novo Certificado no "jwks_uri".
- Continue entrando com o Certificado Existente até que o cache do Microsoft Entra ID seja atualizado, expirado ou renovado (a cada 2 dias).
- Comece a entrar com o Novo Certificado.
Não publicamos cronograma para substituições de chaves. O serviço dependente deve estar preparado para lidar com substituições imediatas e periódicas. Sugerimos o uso de uma biblioteca dedicada desenvolvida para essa finalidade, como azure-activedirectory-identitymodel-extensions-for-dotnet. Para obter mais informações, confira Substituição de chave de assinatura no Microsoft Entra ID.
Descoberta de metadados do Microsoft Entra ID
Os provedores também precisam recuperar as chaves públicas do Microsoft Entra ID para validar os tokens emitidos pelo Microsoft Entra ID.
Pontos de extremidade de descoberta de metadados do Microsoft Entra ID:
- Azure global:
https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration - Azure for US Government:
https://login.microsoftonline.us/common/v2.0/.well-known/openid-configuration - Microsoft Azure operado pela 21Vianet:
https://login.partner.microsoftonline.cn/common/v2.0/.well-known/openid-configuration
Usando o identificador de chave pública do token (o "kid" da Assinatura Web JSON (JWS)), é possível determinar qual das chaves obtidas da propriedade jwks_uri deve ser usada para validar a assinatura do token do Microsoft Entra ID.
Validando tokens emitidos pelo Microsoft Entra ID
Para informações sobre como validar os tokens emitidos pelo Microsoft Entra ID, veja Validação de um token ID. Não há etapas específicas para os consumidores de nossos metadados de descoberta.
A biblioteca de validação de tokens da Microsoft tem todos os detalhes sobre as especificidades da validação de tokens que estão documentados, ou eles podem ser verificados navegando pelo código-fonte. Para obter um exemplo, confira Exemplos do Azure.
Depois que a validação for bem-sucedida, você poderá trabalhar com o conteúdo das declarações para obter os detalhes do usuário e do seu locatário.
Observação
É importante validar o id_token_hint para garantir que o id_token_hint seja de um locatário da Microsoft e represente a sua integração. O id_token_hint deve ser totalmente validado, especialmente a assinatura, o emissor e a audiência, bem como os outros valores de declaração.
Chamada do Microsoft Entra ID para o provedor de identidade externa
O Microsoft Entra ID usa o fluxo implícito de OIDC para se comunicar com o provedor de identidade externo. Usando esse fluxo, a comunicação com o provedor é feita exclusivamente usando o ponto de extremidade da autorização do provedor. Para informar ao provedor sobre o usuário para quem o Microsoft Entra ID está fazendo a solicitação, o Microsoft Entra ID passa um token através do parâmetro id_token_hint.
Essa chamada é feita por meio de uma solicitação POST porque a lista de parâmetros passados para o provedor é grande. Uma lista grande impede o uso de navegadores que limitam o comprimento de uma solicitação GET.
Os parâmetros da solicitação de Autenticação são listados na tabela a seguir.
Observação
A menos que estejam listados na tabela a seguir, outros parâmetros na solicitação devem ser ignorados pelo provedor.
| Parâmetro de consulta de autenticação | Valor | Descrição |
|---|---|---|
| scope | openid | |
| response_type | Id_token | O valor usado para o fluxo implícito. |
| response_mode | form_post | Usamos o formulário POST para evitar problemas com URLs grandes. Esperamos que todos os parâmetros sejam enviados no corpo da solicitação. |
| client_id | A ID do cliente fornecida ao Microsoft Entra ID pelo provedor de identidade externo, como ABCD. Para mais informações, veja Descrição do método de autenticação externa. | |
| redirect_url | O Uniform Resource Identifier (URI) de redirecionamento para onde o provedor de identidade externo envia a resposta (id_token_hint). | |
| Veja um exemplo depois desta tabela. | ||
| nonce | Uma cadeia de caracteres aleatória gerada pelo Microsoft Entra ID. Pode ser a ID da sessão. Se fornecida, precisa ser retornada na resposta ao Microsoft Entra ID. | |
| estado | Se passada, o provedor deve retornar o estado na sua resposta. O Microsoft Entra ID usa o estado para manter o contexto sobre a chamada. | |
| id_token_hint | Um token emitido pelo Microsoft Entra ID para o usuário final, e passado para o benefício do provedor. | |
| declarações | Um blob JSON que contém as declarações solicitadas. Para detalhes sobre o formato deste parâmetro, veja parâmetro de solicitação de declarações da documentação do OIDC, e um exemplo após esta tabela. | |
| ID da solicitação de cliente | Um valor GUID | Um provedor pode registrar esse valor para ajudar a solucionar problemas. |
Exemplo de um URI de redirecionamento
Os Uniform Resource Identifiers (URIs) de redirecionamento devem ser registrados junto ao provedor fora da banda. Os URIs de redirecionamento que podem ser enviados são:
- Azure Global:
https://login.microsoftonline.com/common/federation/externalauthprovider - Azure for US Government:
https://login.microsoftonline.us/common/federation/externalauthprovider - Microsoft Azure operado pela 21Vianet:
https://login.partner.microsoftonline.cn/common/federation/externalauthprovider
Exemplo de um EAM que satisfaz a MFA
Aqui está um exemplo de uma autenticação onde um EAM satisfaz o MFA. Este exemplo ajuda um provedor a saber quais declarações o Microsoft Entra ID espera.
A combinação dos valores acr e amr é utilizada pelo Microsoft Entra ID para validar que:
- O método de autenticação usado para o segundo fator satisfaz o requisito de MFA
- O método de autenticação é diferente em "tipo" do método usado para completar o primeiro fator na entrada do Microsoft Entra ID
{
"id_token": {
"acr": {
"essential": true,
"values":["possessionorinherence"]
},
"amr": {
"essential": true,
"values": ["face", "fido", "fpt", "hwk", "iris", "otp", "pop", "retina", "sc", "sms", "swk", "tel", "vbm"]
}
}
}
Declarações padrão de Id_token_hint
Esta seção descreve o conteúdo necessário do token passado como id_token_hint na solicitação feita ao provedor. O token pode conter mais declarações do que as listadas na tabela a seguir.
| Declaração | Valor | Descrição |
|---|---|---|
| iss | Identifica o serviço de token de segurança (STS) que constrói e retorna o token e o locatário do Microsoft Entra ID no qual o usuário se autenticou. O aplicativo deve usar a parte do GUID da declaração para restringir o conjunto de locatários que podem entrar no aplicativo, se aplicável. O emissor deve corresponder à URL do emissor encontrada nos metadados JSON de descoberta OIDC para o locatário em que o usuário entrou. | |
| aud | O público-alvo deve ser definido como a ID do cliente do provedor de identidade externa para o Microsoft Entra ID. | |
| exp | O tempo de expiração é definido para expirar pouco tempo após o tempo de emissão, suficiente para evitar problemas de distorção de tempo. Como esse token não é destinado à autenticação, não há motivo para que sua validade dure muito além da solicitação. | |
| iat | Define o tempo de emissão como de costume. | |
| tid | A ID do locatário é para anunciar o locatário ao provedor. Representa o locatário do Microsoft Entra ID de onde o usuário faz parte. | |
| oid | O identificador imutável de um objeto na plataforma de identidade da Microsoft. Nesse caso, é uma conta de usuário. Também pode ser usada para realizar verificações de autorização com segurança e como uma chave em tabelas de banco de dados. Essa ID identifica exclusivamente o usuário entre aplicativos. Duas assinaturas diferentes que entram no mesmo usuário recebem o mesmo valor na declaração OID. Portanto, o OID pode ser usado em consultas a serviços online da Microsoft, como o Microsoft Graph. | |
| preferred_username | Fornece um valor legível que identifica a entidade do token. Não há garantia de que esse valor seja exclusivo dentro de um locatário, e que destina-se apenas para fins de exibição. | |
| sub | Identificador de assunto para o usuário final no Emissor. O item mais importante sobre o qual o token declara informações, como o usuário de um aplicativo. Esse valor é imutável e não pode ser reatribuído nem reutilizado. Pode ser usado para executar verificações de autorização de forma segura, por exemplo, quando o token é usado para acessar um recurso, e pode ser usado como uma chave nas tabelas de banco de dados. Como o assunto está sempre presente nos tokens emitidos pelo Microsoft Entra ID, recomendamos usar esse valor em um sistema de autorização de uso geral. No entanto, o assunto é um identificador de paridade, ou seja, é exclusivo a uma ID de aplicativo específica. Isso significa que, se um único usuário acessar dois aplicativos diferentes usando duas IDs de cliente diferentes, esses aplicativos receberão dois valores diferentes para a declaração do assunto. Esse resultado pode ser desejado ou não, dependendo dos requisitos de arquitetura e de privacidade. Confira também a declaração OID (que permanece a mesma em aplicativos dentro de um locatário). |
Para evitar que isso seja usado para qualquer outra coisa que não seja uma dica, o token é emitido como expirado. O token é assinado e pode ser verificado usando os metadados de descoberta do Microsoft Entra ID publicados.
Declarações opcionais do Microsoft Entra ID
Provedores que necessitam de declarações opcionais do Microsoft Entra ID podem configurá-las para id_token. Para saber mais, confira Declarações opcionais.
Uso recomendado de declarações
A Microsoft recomenda que os provedores associem as contas de seus usuários às contas no Azure AD usando as declarações OID e TID. Essas duas declarações têm a garantia de serem exclusivas para cada conta dentro do locatário.
Exemplo de um id_token_hint
Aqui está um exemplo de id_token_hint para um membro de diretório:
{
"typ": "JWT",
"alg": "RS256",
"kid": "C2dE3fH4iJ5kL6mN7oP8qR9sT0uV1w"
}.{
"ver": "2.0",
"iss": "https://login.microsoftonline.com/aaaabbbb-0000-cccc-1111-dddd2222eeee/v2.0",
"sub": "mBfcvuhSHkDWVgV72x2ruIYdSsPSvcj2R0qfc6mGEAA",
"aud": "00001111-aaaa-2222-bbbb-3333cccc4444",
"exp": 1536093790,
"iat": 1536093791,
"nbf": 1536093791,
"name": "Test User 2",
"preferred_username": "testuser2@contoso.com"
"oid": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
"tid": "aaaabbbb-0000-cccc-1111-dddd2222eeee"
}.
Aqui está um exemplo de id_token_hint para um usuário convidado no locatário:
{
"typ": "JWT",
"alg": "RS256",
"kid": "C2dE3fH4iJ5kL6mN7oP8qR9sT0uV1w"
}.{
"ver": "2.0",
"iss": "https://login.microsoftonline.com/9122040d-6c67-4c5b-b112-36a304b66dad/v2.0",
"sub": "mBfcvuhSHkDWVgV72x2ruIYdSsPSvcj2R0qfc6mGEAA",
"aud": "00001111-aaaa-2222-bbbb-3333cccc4444",
"exp": 1536093790,
"iat": 1536093791,
"nbf": 1536093791,
"name": "External Test User (Hotmail)",
"preferred_username": "externaltestuser@hotmail.com",
"oid": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
"tid": "aaaabbbb-0000-cccc-1111-dddd2222eeee"
}.
Ações sugeridas para provedores de identidade externa
Sugerimos que provedores de identidade externa concluam estes passos. A lista não está completa, e os provedores podem concluir outras etapas de validação se acharem necessário.
- Na solicitação:
- Verifique se o redirect_uri foi publicado é fornecido na chamada do Microsoft Entra ID para o provedor de identidade externa.
- Verifique se o client_id tem um valor atribuído ao Microsoft Entra ID, como ABCD.
- O provedor deve primeiro validar o id_token_hint que lhe é apresentado pelo Microsoft Entra ID.
- Nas declarações do id_token_hint:
- Opcionalmente, eles podem fazer uma chamada ao Microsoft Graph para buscar outros detalhes sobre este usuário. As declarações oid e tid no id_token_hint são úteis neste contexto. Para mais detalhes sobre as declarações fornecidas no id_token_hint, confira Declarações padrão do id_token_hint.
- Em seguida, realize qualquer outra atividade de autenticação que o produto do provedor foi desenvolvido para fazer.
- Dependendo do resultado das ações do usuário e outros fatores, o provedor então construirá e enviará uma resposta de volta ao Microsoft Entra ID, conforme explicado na próxima seção.
Processamento da resposta do provedor pelo Microsoft Entra ID
O provedor precisa postar (POST) uma resposta de volta ao redirect_uri. Os seguintes parâmetros devem ser fornecidos em uma resposta bem-sucedida:
| Parâmetro | Valor | Descrição |
|---|---|---|
| id_token | O token emitido pelo provedor de identidade externa. | |
| estado | O mesmo estado que foi passado na solicitação, se houver. Caso contrário, esse valor não deve estar presente. |
Se der certo, o provedor emitirá um id_token para o usuário. O Microsoft Entra ID usa os metadados OIDC publicados para verificar se o token contém as declarações esperadas e realiza outras validações de token exigidas pelo OIDC.
| Declaração | Valor | Descrição |
|---|---|---|
| iss | Emissor – deve corresponder ao emissor dos metadados de descoberta do provedor. | |
| aud | Público – a ID do cliente do Microsoft Entra ID. Confira client_id em Chamada do Microsoft Entra ID para o provedor de identidade externa. | |
| exp | Tempo de expiração – definido como de costume. | |
| iat | Tempo de emissão – definido como de costume. | |
| sub | Assunto – deve corresponder ao sub do id_token_hint enviado para iniciar essa solicitação. | |
| nonce | O mesmo nonce que foi passado na solicitação. | |
| acr | As declarações acr para a solicitação de autenticação. Esse valor deve corresponder a um dos valores da solicitação enviada para iniciar esta solicitação. Apenas uma declaração acr deve ser retornada. Para conferir lista de declarações, acesse Declarações acr com suporte. | |
| amr | As declarações amr para o método de autenticação usado na autenticação. Esse valor deve ser retornado como uma matriz e apenas uma declaração de método deve ser retornada. Para conferir a lista de declarações, acesse Declarações amr com suporte. |
Declarações acr com suporte
| Declaração | Observações |
|---|---|
| possessionorinherence | A autenticação deve ser realizada com um fator baseado em posse ou inerência. |
| knowledgeorpossession | A autenticação deve ser realizada com um fator baseado em conhecimento ou posse. |
| knowledgeorinherence | A autenticação deve ser realizada com um fator baseado conhecimento ou inerência. |
| knowledgeorpossessionorinherence | A autenticação deve ser realizada com um fator baseado em conhecimento, posse ou inerência. |
| conhecimento | A autenticação deve ser realizada com um fator baseado em conhecimento. |
| possession | A autenticação deve ser realizada com um fator baseado em posse. |
| inherence | A autenticação deve ser realizada com um fator baseado em inerência. |
Declarações amr com suporte
| Declaração | Observações |
|---|---|
| face | Biometria com reconhecimento facial |
| fido | O FIDO2 foi utilizado |
| fpt | Biometria com impressão digital |
| hwk | Comprovação de posse de chave protegida por hardware |
| Iris | Biometria com reconhecimento de íris |
| otp | Senha de uso único |
| pop | Prova de posse |
| retina | Biometria com reconhecimento de retina |
| sc | Cartão inteligente |
| sms | Confirmação por mensagem de texto para número cadastrado |
| swk | Confirmação da presença de uma chave protegida por software |
| tel | Confirmação por telefone |
| vbm | Biometria com impressão digital |
O Microsoft Entra ID exige que a MFA esteja cumprida para emitir um token com declarações de MFA. Portanto, somente métodos com um tipo diferente podem cumprir o requisito do segundo fator. Conforme mencionado anteriormente, os diferentes tipos de método que podem ser usados para cumprir o segundo fator são conhecimento, posse e inerência.
O Microsoft Entra ID valida o mapeamento de tipos com base na tabela a seguir.
| Método Claim | Tipo | Observações |
|---|---|---|
| face | Inerência | Biometria com reconhecimento facial |
| fido | Posse | O FIDO2 foi utilizado. Algumas implementações também podem exigir biometria, mas o tipo de método baseado em posse é mapeado porque é o principal atributo de segurança. |
| fpt | Inerência | Biometria com impressão digital |
| hwk | Posse | Comprovação de posse de chave protegida por hardware |
| Iris | Inerência | Biometria com reconhecimento de íris |
| otp | Posse | Senha de uso único |
| pop | Posse | Prova de posse |
| retina | Inerência | Biometria com reconhecimento de retina |
| sc | Posse | Cartão inteligente |
| sms | Posse | Confirmação por mensagem de texto para número cadastrado |
| swk | Posse | Prova de presença de uma chave protegida por software |
| tel | Posse | Confirmação por telefone |
| vbm | Inerência | Biometria com impressão digital |
Se o token não apresentar problemas, o Microsoft Entra ID considera que o MFA foi atendido e emite um token para o usuário final. Caso contrário, a solicitação do usuário final falhará.
A falha é indicada pela emissão de parâmetros de resposta ao erro.
| Parâmetro | Valor | Descrição |
|---|---|---|
| Erro | Um código de erro ASCII, como access_denied ou temporarily_unavailable. |
O Microsoft Entra ID considera a solicitação bem-sucedida se o parâmetro id_token estiver presente na resposta e se o token for válido. Caso contrário, a solicitação é considerada malsucedida. O Microsoft Entra ID falha na tentativa de autenticação original devido ao requisito da política de Acesso Condicional.
O Microsoft Entra ID abandona o estado da tentativa de autenticação cerca de 10 minutos após o redirecionamento para o provedor.
Manuseio da resposta ao erro do Microsoft Entra ID
Os serviços do Microsoft Azure usam um correlationId para correlacionar chamadas em vários sistemas internos e externos. Ele serve como um identificador comum de toda a operação ou fluxo que potencialmente envolve várias chamadas HTTP. Quando ocorre um erro durante qualquer uma das operações, a resposta contém um campo denominado ID de Correlação.
Ao entrar em contato com o suporte da Microsoft ou um serviço semelhante, forneça o valor dessa ID de Correlação, pois ela ajuda a acessar a telemetria e os logs mais rapidamente.
Por exemplo:
ENTRA IDSTS70002: erro ao validar as credenciais. ENTRA IDSTS50012: falha na verificação de assinatura do token de ID externa do emissor "https://sts.XXXXXXXXX.com/auth/realms/XXXXXXXXXmfa". A KeyID do token é 'A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u' ID de rastreamento: 0000aaaa-11bb-cccc-dd22-eeeeee333333 ID de correlação: aaaa0000-bb11-2222-33cc-444444dddddd Carimbo de data/hora: 2023-07-24 16:51:34Z
Controles personalizados e EAMs
No Microsoft Entra ID, os EAMs e os controles personalizados de Acesso Condicional podem operar paralelamente enquanto os clientes se preparam e migram para os EAMs.
Os clientes que atualmente usam uma integração com um provedor externo por meio de controles personalizados podem continuar a usá-los, assim como as políticas de Acesso Condicional configuradas para gerenciar o acesso. Recomenda-se que os administradores criem um conjunto paralelo de políticas de Acesso Condicional durante o período de migração:
As políticas devem utilizar o controle de concessão Exigir autenticação multifator em vez do controle personalizado.
Observação
Os controles de concessão baseados em níveis de autenticação, incluindo a força interna da MFA, não são atendidos pelo EAM. As políticas devem ser configuradas apenas com a opção Exigir autenticação multifator. Estamos trabalhando ativamente para oferecer suporte a EAMs com pontos fortes de autenticação.
A nova política pode ser testada primeiro com um subconjunto de usuários. O grupo de teste seria excluído da política que requer os controles personalizados e incluído na política que exige MFA. Depois que a administração estiver confiante de que a política que exige MFA é atendida pelo EAM, o administrador poderá incluir todos os usuários necessários na política com a concessão de MFA e a política configurada para controles personalizados pode ser alterada para Desativada.
Suporte à integração
Se você tiver problemas ao desenvolver a integração do EAM com o Microfone,a equipe de Engenharia de Experiência do Cliente (CxE) da Microsoft para Fornecedores Independentes de Soluções (ISV) poderá ajudar. Para entrar em contato com a equipe de CxE para ISV, envie uma solicitação de assistência.
Referências
Glossário
| Termo | Descrição |
|---|---|
| MFA | Autenticação multifator. |
| EAM | Um método de autenticação externa é um método de autenticação de um provedor diferente do Microsoft Entra ID que é usado como parte da autenticação de um usuário. |
| OIDC | O OpenID Connect é um protocolo de autenticação criado com base no OAuth 2.0. |
| 00001111-aaaa-2222-bbbb-3333cccc4444 | Um exemplo de um appid integrado para um método de autenticação externa. |
Próximas etapas
Para mais informações sobre como configurar um EAM no Centro de administração do Microsoft Entra, confira Gerenciar um método de autenticação externa no Microsoft (Versão prévia).