Referência do provedor de método externo de autenticação multifator Microsoft Entra (Visualização)
Este tópico descreve como um provedor de autenticação externo se conecta à autenticação multifator (MFA) do Microsoft Entra. Um provedor de autenticação externo pode se integrar com locatários do Microsoft Entra ID como um método de autenticação externa (EAM). Um EAM pode satisfazer o segundo fator de um requisito de MFA para acesso a um recurso ou aplicativo. Os EAMs exigem pelo menos uma licença do Microsoft Entra ID P1.
Quando um usuário faz logon, 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 ao login, dependendo de seus parâmetros. Esses parâmetros incluem usuários e grupos, aplicativos, plataforma, nível de risco de entrada e muito mais.
Com base nos requisitos de autenticação, o usuário pode precisar entrar com outro fator para atender ao requisito de MFA. O segundo fator precisa complementar o tipo de primeiro fator.
Os EAMs são adicionados ao Microsoft Entra ID pelo administrador do locatário. Se um locatário precisar de um EAM para MFA, considera-se que a entrada atende ao requisito de MFA depois que o Microsoft Entra ID valida ambos:
- O primeiro fator completado com o Microsoft Entra ID
- O segundo fator completado com o EAM
Essa validação atende ao requisito de MFA para dois ou mais tipos de métodos de:
- Algo que você sabe (conhecimento)
- Algo que você tem (posse)
- Algo que você é (inerência)
Os EAMs são implementados em cima do Open ID Connect (OIDC). Essa implementação requer 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
- Um URL onde os certificados públicos do provedor são publicados
Vamos ver mais de perto como o login funciona com um EAM:
- Um usuário tenta entrar com um primeiro fator, como uma senha, em 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 requer MFA.
- O usuário escolhe o EAM como um segundo fator.
- O Microsoft Entra ID redireciona a sessão do navegador do usuário para a URL do EAM:
- Esse URL é descoberto a partir do URL de descoberta provisionado por um administrador quando ele 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 externo valida que o token veio do Microsoft Entra ID e verifica o conteúdo do token.
- O provedor de autenticação externo pode, opcionalmente, fazer uma chamada para o Microsoft Graph para buscar informações adicionais sobre o usuário.
- O provedor de autenticação externo executa todas as ações que julgar necessárias, como autenticar o usuário com alguma credencial.
- O provedor de autenticação externo redireciona o usuário de volta para o 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 externo configurado e, em seguida, verifica o conteúdo do token.
- O Microsoft Entra ID valida o token em relação aos requisitos.
- O usuário satisfez o 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 externo com o Microsoft Entra ID
Um aplicativo que represente a integração é necessário 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 privilegiada precisam conceder consentimento para habilitar a integração para seu locatário.
Um aplicativo multilocatário reduz a chance de configuração incorreta em cada locatário. Ele também permite que os provedores façam alterações em metadados, como URLs de resposta, em um só lugar, em vez de exigir que cada locatário faça as alterações.
Para configurar um aplicativo multilocatário, o administrador do provedor deve primeiro:
Crie um locatário do Microsoft Entra ID se ele ainda não tiver um.
Registe uma aplicação no seu inquilino.
Defina os tipos de Conta Suportada do aplicativo como: Contas em qualquer diretório organizacional (Qualquer locatário do Microsoft Entra ID - Multilocatário).
Adicione a permissão
openiddelegada eprofiledo Microsoft Graph ao aplicativo.Não publique nenhum escopo neste aplicativo.
Adicione as URLs de authorization_endpoint válidas do provedor de identidade externo a esse aplicativo como URLs de resposta.
Nota
O authorization_endpoint fornecido no documento de descoberta do provedor deve ser adicionado como uma URL de redirecionamento no registro do aplicativo. Caso contrário, você receberá o seguinte erro: ENTRA IDSTS50161: Falha ao validar url de autorização do provedor de declarações externo!
O processo de registro do aplicativo cria um aplicativo com várias propriedades. Essas propriedades são necessárias para o nosso cenário.
| Property | Description |
|---|---|
| ID do Objeto | O provedor pode usar a ID do objeto com o Microsoft Graph para consultar as informações do aplicativo. O provedor pode usar o ID do objeto para recuperar e editar programaticamente as informações do aplicativo. |
| ID da aplicação | O provedor pode usar o ID do aplicativo como o ClientId de seu aplicativo. |
| URL da página inicial | O URL da página inicial do provedor não é usado para nada, mas é necessário como parte do registro do aplicativo. |
| URLs de Resposta | URLs de redirecionamento válidos para o provedor. Deve-se 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 a ID do Microsoft Entra recupera por meio da descoberta OIDC para a URL do host. |
Um aplicativo para cada locatário também é um modelo válido para suportar a integração. Se você usar um registro de locatário único, o administrador do locatário precisará criar um registro de aplicativo com as propriedades na tabela anterior para um aplicativo de locatário único.
Nota
O consentimento do administrador para o aplicativo é necessário no locatário que usa o EAM. Se o consentimento não for concedido, o seguinte erro aparecerá quando um administrador tentar usar o EAM: AADSTS900491: Principal <de serviço cujo ID> de aplicativo não foi encontrado.
Configurar afirmações opcionais
Um provedor pode configurar mais declarações usando declarações opcionais para id_token.
Nota
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 para o governo dos EUA, cada ambiente de nuvem exigirá um aplicativo e uma ID de aplicativo diferentes.
Adicionar um EAM ao ID do Microsoft Entra
As informações do provedor de identidade externo 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 no objeto de lista da política. Cada entrada deve indicar:
- Se o método estiver 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 Exigir Concessão de MFA para definir o requisito de MFA para o início de sessão do utilizador. Atualmente, não há suporte para métodos de autenticação externos com pontos fortes de autenticação.
Para obter mais informações sobre como adicionar um método de autenticação externa no centro de administração do Microsoft Entra, consulte Gerenciar um método de autenticação externa no Microsoft Entra ID (Visualização).
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 externo precisa fornecer um ponto de extremidade de descoberta OIDC. Este ponto de extremidade é usado para obter mais dados de configuração. O URL completo, incluindo .configuração oidc bem conhecida/, deve ser incluída na URL de descoberta configurada quando o EAM é criado.
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 de comprimento de conteúdo 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 obter o documento OIDC com os valores para Metadados do provedor, consulte Metadados do provedor.
| Valor dos metadados | Value | Comentários |
|---|---|---|
| Emissor | Essa URL deve corresponder à URL do host usada para descoberta e à declaração de 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. [!NOTA] O parâmetro JSON Web Key (JWK) x5c 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 | Microsoft suporta RS256 | |
| claim_types_supported | normal | Esta 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="
]
}
]
}
Nota
O parâmetro JWK x5c 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 metadados retornados pelo provedor, incluindo as chaves. O cache de metadados do provedor impede uma chamada de descoberta sempre que o Microsoft Entra ID fala com um provedor de identidade externo.
Esse cache é atualizado a cada 24 horas (um dia). Veja como sugerimos que um provedor transfira suas chaves:
- Publique o certificado existente e o novo certificado no "jwks_uri".
- Continue assinando com o Certificado Existente até que o cache de ID do Microsoft Entra seja atualizado, expirado ou atualizado (a cada 2 dias).
- Mude para assinar com New Cert.
Não publicamos agendas para substituições de chaves. O serviço dependente deve estar preparado para lidar com rollovers imediatos e periódicos. Sugerimos usar uma biblioteca dedicada criada para essa finalidade, como azure-activedirectory-identitymodel-extensions-for-dotnet. Para obter mais informações, consulte Substituindo a chave de assinatura na ID do Microsoft Entra.
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 para o governo dos EUA:
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 JSON Web Signature (JWS)), pode-se determinar qual das chaves recuperadas 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 obter informações sobre como validar os tokens emitidos pelo Microsoft Entra ID, consulte Validação e token de ID. Não há etapas especiais para os consumidores de nossos metadados de descoberta.
A biblioteca de validação de token da Microsoft tem todos os detalhes sobre as especificidades da validação de token que são documentados, ou eles podem ser verificados a partir da navegação no código-fonte. Para obter um exemplo, consulte Exemplos do Azure.
Quando a validação for bem-sucedida, você poderá trabalhar com a carga útil de declarações para obter detalhes do usuário e de seu locatário.
Nota
É importante validar o id_token_hint para garantir que o id_token_hint seja de um locatário da Microsoft e represente sua integração. Os id_token_hint devem ser totalmente validados, particularmente a assinatura, o emissor, o público, bem como os outros valores de reivindicação.
Chamada de ID do Microsoft Entra para o provedor de identidade externo
O Microsoft Entra ID usa o fluxo implícito do 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 de autorização do provedor. Para que o provedor saiba o usuário para o qual 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 de solicitação de autenticação estão listados na tabela a seguir.
Nota
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 | Description |
|---|---|---|
| âmbito | 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 do pedido. |
| client_id | A ID do cliente fornecida ao Microsoft Entra ID pelo provedor de identidade externo, como ABCD. Para obter mais informações, consulte Descrição do método de autenticação externa. | |
| redirect_url | O URI (Uniform Resource Identifier) de redirecionamento para o qual o provedor de identidade externo envia a resposta (id_token_hint). | |
| Veja um exemplo após esta tabela. | ||
| nonce | Uma cadeia de caracteres aleatória gerada pelo Microsoft Entra ID. Pode ser o ID da sessão. Se fornecido, ele precisa ser retornado na resposta de volta para o Microsoft Entra ID. | |
| state | Se aprovado, o provedor deve retornar o estado em 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. | |
| afirmações | Um blob JSON que contém as declarações solicitadas. Para obter detalhes sobre o formato desse parâmetro, consulte o parâmetro de solicitação de declarações da documentação do OIDC e um exemplo após esta tabela. | |
| ID de solicitação do cliente | Um valor GUID | Um provedor pode registrar esse valor para ajudar a solucionar problemas. |
Exemplo de um URI de redirecionamento
Os URIs (Uniform Resource Identifiers) de redirecionamento devem ser registrados no provedor off-band. Os URIs de redirecionamento que podem ser enviados são:
- Azure Global:
https://login.microsoftonline.com/common/federation/externalauthprovider - Azure para o governo dos EUA:
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 AMF
Aqui está um exemplo de uma autenticação em que um EAM satisfaz MFA. Este exemplo ajuda um provedor a saber quais declarações o Microsoft Entra ID espera.
A combinação dos acr valores e amr é usada pelo Microsoft Entra ID para validar:
- O método de autenticação usado para o segundo fator satisfaz o requisito de MFA
- O método de autenticação difere em 'tipo' do método usado para concluir o primeiro fator para entrar no ID do Microsoft Entra
{
"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 de Id_token_hint padrão
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 na tabela a seguir.
| Afirmação | valor | Description |
|---|---|---|
| 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. Seu aplicativo deve usar a parte 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 dos metadados JSON de descoberta OIDC para o locatário onde o usuário entrou. | |
| aud | A audiência deve ser definida como a ID do cliente do provedor de identidade externo para a ID do Microsoft Entra. | |
| exp | O tempo de expiração é definido para expirar um curto período de tempo após o tempo de emissão, suficiente para evitar problemas de distorção de tempo. Como esse token não se destina à autenticação, não há razão para que sua validade dure muito mais do que a solicitação. | |
| iat | Defina a hora de emissão como habitualmente. | |
| TID | O ID do locatário é para anunciar o locatário para o provedor. Ele representa o locatário do Microsoft Entra ID do qual o usuário é. | |
| Oide | O identificador imutável para um objeto na plataforma de identidade da Microsoft. Neste caso, é uma conta de usuário. Ele também pode ser usado para executar verificações de autorização com segurança e como uma chave em tabelas de banco de dados. Esse ID identifica exclusivamente o usuário entre aplicativos. Dois aplicativos diferentes que entram no mesmo usuário recebem o mesmo valor na declaração oid. Assim, o oid pode ser usado em consultas a serviços online da Microsoft, como o Microsoft Graph. | |
| preferred_username | Fornece um valor legível por humanos que identifica o requerente do token. Não é garantido que esse valor seja exclusivo dentro de um locatário e destina-se apenas para fins de exibição. | |
| sub | Identificador de assunto para o usuário final no Emissor. A entidade sobre a qual o token afirma informações, como o usuário de um aplicativo. Esse valor é imutável e não pode ser reatribuído ou reutilizado. Ele pode ser usado para executar verificações de autorização com segurança, como quando o token é usado para acessar um recurso, e pode ser usado como uma chave em tabelas de banco de dados. Como o assunto está sempre presente nos tokens que o Microsoft Entra ID emite, recomendamos usar esse valor em um sistema de autorização de uso geral. O sujeito é, no entanto, um identificador par; é exclusivo para um ID de aplicativo específico. Portanto, se um único usuário entrar em dois aplicativos diferentes usando duas IDs de cliente diferentes, esses aplicativos receberão dois valores diferentes para a declaração de assunto. Este resultado pode ou não ser desejado, dependendo da sua arquitetura e requisitos de privacidade. Consulte também a declaração oid (que permanece a mesma em todos os aplicativos dentro de um locatário). |
Para evitar que ele 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 publicados do Microsoft Entra ID.
Declarações opcionais do Microsoft Entra ID
Se um provedor precisar de declarações opcionais do Microsoft Entra ID, você poderá configurar as seguintes declarações opcionais para id_token: given_name, family_name, preferred_username, upn. Para obter mais informações, consulte Declarações opcionais.
Utilização recomendada de alegações
A Microsoft recomenda associar contas no lado do provedor à conta no Azure AD usando as declarações oid e tid. Estas duas reivindicações são garantidamente únicas para a conta no inquilino.
Exemplo de uma id_token_hint
Aqui está um exemplo de um id_token_hint para um membro do 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 da dica id_token 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 externos
Sugerimos que os provedores de identidade externos concluam essas etapas. A lista não é exaustiva e os fornecedores devem concluir outras etapas de validação como acharem melhor.
- Do pedido:
- Certifique-se de que o redirect_uri é publicado fornecido na chamada de ID do Microsoft Entra para o provedor de identidade externo.
- Verifique se o client_id tem um valor atribuído à ID do Microsoft Entra, como ABCD.
- O provedor deve primeiro validar o id_token_hint que lhe é apresentado pelo Microsoft Entra ID.
- Das alegações na id_token_hint:
- Opcionalmente, eles podem fazer uma chamada para o Microsoft Graph para buscar outros detalhes sobre esse usuário. As alegações de oide e tid no id_token_hint são úteis a este respeito. Para obter detalhes sobre as declarações fornecidas no id_token_hint, consulte Declarações de id_token_hint padrão.
- Em seguida, realize qualquer outra atividade de autenticação para a qual o produto do provedor tenha sido criado.
- Dependendo do resultado das ações do usuário e de outros fatores, o provedor construiria e enviaria uma resposta de volta para o Microsoft Entra ID, conforme explicado na próxima seção.
Processamento do Microsoft Entra ID da resposta do provedor
O provedor precisa POSTAR uma resposta de volta ao redirect_uri. Os seguintes parâmetros devem ser fornecidos em caso de resposta bem-sucedida:
| Parâmetro | valor | Description |
|---|---|---|
| id_token | O token emitido pelo provedor de identidade externo. | |
| state | O mesmo estado que foi passado no pedido, se houver. Caso contrário, esse valor não deve estar presente. |
Em caso de sucesso, 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 faz qualquer outra validação do token que o OIDC exige.
| Afirmação | valor | Description |
|---|---|---|
| iss | Emissor – deve corresponder ao emissor a partir dos metadados de descoberta do provedor. | |
| aud | Audiência – a ID do cliente Microsoft Entra ID. Consulte client_id na chamada do Microsoft Entra ID para o provedor de identidade externo. | |
| exp | Tempo de expiração – definido como de costume. | |
| iat | Hora de emissão – definida como habitualmente. | |
| sub | Assunto – deve corresponder ao subwoofer do id_token_hint enviado para iniciar este pedido. | |
| nonce | O mesmo nonce que foi passado no pedido. | |
| acr | O acr declara para a solicitação de autenticação. Esse valor deve corresponder a um dos valores da solicitação enviada para iniciar essa solicitação. Apenas uma reivindicação acr deve ser devolvida. Para obter a lista de declarações, consulte Declarações acr suportadas. | |
| RAM | 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 obter a lista de declarações, consulte Declarações amr suportadas. |
Reivindicações acr suportadas
| Afirmação | Notas |
|---|---|
| posse ou inerência | A autenticação deve ocorrer com um fator baseado na posse ou inerência. |
| conhecimento ou posse | A autenticação deve ocorrer com um fator baseado no conhecimento ou na posse. |
| conhecimento ou inerência | A autenticação deve ocorrer com um fator baseado em conhecimento ou inerência. |
| conhecimento, posse ou inerência | A autenticação deve ocorrer com um fator baseado no conhecimento, posse ou inerência. |
| knowledge | A autenticação deve ocorrer com fator baseado em conhecimento. |
| Posse | A autenticação deve ocorrer com fator baseado na posse. |
| inerência | A autenticação deve ocorrer com fator baseado em inerência. |
Declarações amr suportadas
| Afirmação | Notas |
|---|---|
| face | Biometria com reconhecimento facial |
| Fido | FIDO2 foi utilizado |
| FPT | Biométrico com impressão digital |
| HWK | Prova de posse de chave protegida por hardware |
| íris | Biométrica com varredura da íris |
| OTP | Palavra-passe única |
| Pop | Prova de propriedade |
| retina | Biometria do exame de retina |
| SC | Smart card |
| sms | Confirmação por texto para o número registado |
| SWK | Confirmação da presença de uma chave protegida por software |
| Tel. | Confirmação por telefone |
| VBM | Biométrica com impressão de voz |
O Microsoft Entra ID requer que o MFA esteja satisfeito para emitir um token com declarações de MFA. Como resultado, apenas métodos com um tipo diferente podem satisfazer o segundo requisito de fator. Como mencionado anteriormente, os diferentes tipos de método que podem ser usados para satisfazer o segundo fator são conhecimento, posse e inerência.
O Microsoft Entra ID valida o mapeamento de tipo com base na tabela a seguir.
| Método de reivindicação | Type | Notas |
|---|---|---|
| face | Inerência | Biometria com reconhecimento facial |
| Fido | Posse | FIDO2 foi utilizado. Algumas implementações também podem exigir biometria, mas o tipo de método de posse é mapeado porque é o principal atributo de segurança. |
| FPT | Inerência | Biométrico com impressão digital |
| HWK | Posse | Prova de posse de chave protegida por hardware |
| íris | Inerência | Biométrica com varredura da íris |
| OTP | Posse | Palavra-passe monouso |
| Pop | Posse | Prova de propriedade |
| retina | Inerência | Biometria do exame de retina |
| SC | Posse | Smart card |
| sms | Posse | Confirmação por texto para o número registado |
| SWK | Posse | Prova da presença de uma chave protegida por software |
| Tel. | Posse | Confirmação por telefone |
| VBM | Inerência | Biométrica com impressão de voz |
Se nenhum problema for encontrado com o token, o Microsoft Entra ID considerará o MFA satisfeito e emitirá 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 a erros.
| Parâmetro | valor | Description |
|---|---|---|
| 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, o pedido é considerado infrutífero. O Microsoft Entra ID falha na tentativa de autenticação original devido ao requisito da política de Acesso Condicional.
Microsoft Entra ID abandona o estado da tentativa de autenticação em seu final cerca de 5 minutos após o redirecionamento para o provedor.
Tratamento de resposta de 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 chamado ID de correlação.
Quando você 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 credenciais. ENTRA IDSTS50012: Falha na verificação de assinatura do token de ID externo do emissor 'https://sts.XXXXXXXXX.com/auth/realms/XXXXXXXXXmfa'. KeyID do token é 'A1bC2dE3fH4iJ5kL6mN7oP8qR9sT0u' ID de rastreamento: 0000aaa-11bb-cccc-dd22-eeeeee333333 ID de correlação: aaaa0000-bb11-2222-33cc-444444dddddddd 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 em paralelo enquanto os clientes se preparam e migram para EAMs.
Os clientes que atualmente usam uma integração com um provedor externo usando controles personalizados podem continuar a usá-los e quaisquer políticas de Acesso Condicional que eles configuraram para gerenciar o acesso. Recomenda-se aos administradores que criem um conjunto paralelo de políticas de Acesso Condicional durante o período de migração:
As políticas devem usar o controle de concessão Exigir autenticação multifator em vez da concessão de controle personalizado.
Nota
Os controles de concessão com base nos pontos fortes de autenticação, incluindo a força de MFA interna, não são satisfeitos pelo EAM. As políticas só devem ser configuradas com 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 requer MFA. Quando o administrador estiver confortável que a política que requer MFA é satisfeita pelo EAM, o administrador pode 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 movida para Desativado.
Suporte à integração
Se você tiver algum problema ao criar a integração do EAM com o Microsoft Entra ID, o Microsoft Customer Experience Engineering (CxE) Independent Solution Vendor (ISV) poderá ajudar. Para interagir com a equipe CxE ISV, envie uma solicitação de assistência.
Referências
Glossário
| Termo | Description |
|---|---|
| MFA | Autenticação multifator. |
| MEA | Um método de autenticação externo é 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 Open ID Connect é um protocolo de autenticação baseado no OAuth 2.0. |
| 00001111-aaaa-2222-bbbb-3333cccc444 | Um exemplo de um appid integrado para um método de autenticação externo. |
Próximos passos
Para obter mais informações sobre como configurar um EAM no centro de administração do Microsoft Entra, consulte Gerenciar um método de autenticação externa na Microsoft (Visualização).