Referência do fornecedor de métodos externos de autenticação multifator do Microsoft Entra (Versão Prévia)

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 inquilino. Se um inquilino precisar de um EAM para MFA, considera-se que o login atende ao requisito de MFA depois que o Microsoft Entra ID valida ambos:

• O primeiro fator foi concluído com o Microsoft Entra ID
• O segundo fator foi 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ê sabe (conhecimento)
• Algo que tu tens (posse)
• Algo que você é (inerência)

Os EAMs são implementados em cima do Open ID Connect (OIDC). Esta implementação requer pelo menos três pontos de extremidade expostos ao público.

• Um endpoint de descoberta OIDC, tal como descrito em Descoberta de metadados do fornecedor
• 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:

1. Um usuário tenta entrar com um primeiro fator, como uma senha, em um aplicativo protegido pelo Microsoft Entra ID.
2. O Microsoft Entra ID determina que outro fator precisa ser satisfeito. Por exemplo, uma política de Acesso Condicional requer MFA.
3. O usuário escolhe o EAM como um segundo fator.
4. O Microsoft Entra ID redireciona a sessão do navegador do usuário para a URL do EAM:
   1. Esse URL é descoberto a partir do URL de descoberta provisionado por um administrador quando ele criou o EAM.
   2. O aplicativo fornece um token expirado ou quase expirado que contém informações para identificar o usuário e o locatário.
5. O provedor de autenticação externo valida que o token veio do Microsoft Entra ID e verifica o conteúdo do token.
6. O provedor de autenticação externo pode, opcionalmente, fazer uma chamada para o Microsoft Graph para buscar informações adicionais sobre o usuário.
7. O provedor de autenticação externo executa todas as ações que julgar necessárias, como autenticar o usuário com alguma credencial.
8. 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.
9. 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.
10. O Microsoft Entra ID valida o token em relação aos requisitos.
11. 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 utiliza o fornecedor externo.
• Criado como uma aplicação multilocatária. Os administradores de função privilegiada precisam conceder consentimento para habilitar a integração para seu locatário.

Uma aplicação multitenant reduz a chance de configuração incorreta em cada inquilino. 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:

1. Crie uma instância do Microsoft Entra ID caso o utilizador ainda não tenha uma.

2. Registe uma aplicação no respetivo locatário.

3. Defina os tipos de Contas Suportadas do aplicativo como: Contas em qualquer diretório organizacional (Qualquer locatário do Microsoft Entra ID - Multilocatário).

4. Adicione à aplicação as permissões openid e profile como delegadas do Microsoft Graph.

5. Não publique nenhum escopo nesta aplicação.

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

Propriedade	Descrição
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álidas 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 registadas deve corresponder ao prefixo do authorization_endpoint que o 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 utilizar um registo de inquilino único, o administrador do inquilino deve criar um registo de aplicação com as propriedades indicadas na tabela anterior para uma aplicação de inquilino ú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 <ID de aplicativo> não 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 Microsoft Entra ID

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 opção Conceder MFA como Requisito para definir a exigência de MFA para a autenticação de 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 endpoint de descoberta OIDC. Este ponto de extremidade é usado para obter mais dados de configuração. A URL completa, incluindo .bem conhecido/oidc-configuration, deve ser incluída na URL de descoberta configurada quando o EAM é criado.

O ponto de extremidade retorna um documento JSON com metadados do fornecedor 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	Valor	Comentários
Emissor		Essa URL deve corresponder à URL do anfitrião usada para descoberta e ao atributo iss nos tokens emitidos pelo serviço do provedor.
endpoint_de_autorização		O endpoint com o qual o Microsoft Entra ID se comunica para autorização. Este ponto de extremidade deve estar presente como uma das URLs de resposta para as aplicações permitidas.
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.
âmbitos_suportados	OpenID	Outros valores também podem ser incluídos, mas não são obrigatórios.
tipos_de_resposta_suportados	id_token (token de identificação)	Outros valores também podem ser incluídos, mas não são obrigatórios.
tipos_de_assunto_suportados
id_token_signing_alg_values_supported		Microsoft suporta RS256
tipos de pedidos suportados	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. A cache de metadados do provedor impede que seja realizada 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:

1. Publique o certificado existente e o novo certificado no "jwks_uri".
2. Continue assinando com o Certificado Existente até que o cache de ID do Microsoft Entra seja renovado, expirado ou atualizado (a cada 2 dias).
3. Altere para assinar com Novo Certificado.

Não publicamos cronogramas para renovações de chaves. O serviço dependente deve estar preparado para lidar com transferências imediatas e periódicas. Sugerimos usar uma biblioteca dedicada criada para essa finalidade, como azure-activedirectory-identitymodel-extensions-for-dotnet. Para obter mais informações, consulte Rollover da chave de assinatura na Identidade 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 finais 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 estão documentados, ou podem ser verificados através da análise do código-fonte. Para obter um exemplo, consulte Exemplos do Azure.

Quando a validação for bem-sucedida, poderá trabalhar com o payload de reivindicações para obter detalhes do utilizador e do seu inquilino.

Nota

É importante validar o id_token_hint para garantir que o id_token_hint seja de um tenant da Microsoft e represente a sua integração. O id_token_hint deve ser completamente validado, particularmente a assinatura, o emissor, a audiência, bem como outros valores declarados.

Chamada do Microsoft Entra ID para o fornecedor de identidade externo

O Microsoft Entra ID usa o fluxo implícito do OIDC para se comunicar com o provedor de identidade externo. Usando este fluxo, a comunicação com o fornecedor é feita exclusivamente através do endpoint de autorização do fornecedor. 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	Descrição
âmbito	OpenID
tipo_de_resposta	Token_de_identidade	O valor usado para o fluxo implícito.
modo_de_resposta	envio_de_formulário	Usamos o formulário POST para evitar problemas com URLs grandes. Esperamos que todos os parâmetros sejam enviados no corpo do pedido.
ID do cliente		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.
URL de redirecionamento		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. Caso seja fornecido, deverá ser retornado na resposta ao Microsoft Entra ID.
estado		Caso os parâmetros sejam fornecidos, o provedor deve retornar o estado na sua resposta. O Microsoft Entra ID usa o estado para manter o contexto da chamada.
id_token_hint		Um token emitido pelo Microsoft Entra ID para o utilizador final e entregue para benefício do fornecedor.
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 Identificadores Uniformes de Recurso (URIs) de redirecionamento devem ser registados no fornecedor fora de banda. 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 os requisitos de MFA

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 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 na tabela a seguir.

Afirmação	Valor	Descrição
ISS		Identifica o serviço de token de segurança (STS) que constrói e retorna o token e o tenant do Microsoft Entra ID no qual o utilizador 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		O público deve ser definido para 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 a instância do Microsoft Entra ID à qual o utilizador pertence.
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. Duas aplicações diferentes que fazem a autenticação no mesmo utilizador recebem o mesmo valor na afirmação oid. Assim, o oid pode ser usado em consultas a serviços online da Microsoft, como o Microsoft Graph.
nome_de_utilizador_preferido		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.
submarino		Identificador de sujeito para o utilizador final no Emissor. A entidade para a qual o token fornece informações, como o utilizador de uma aplicação. 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 de pares; é exclusivo para o ID de uma aplicação específica. 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 declarações são garantidas como únicas para a conta no locatário.

Exemplo de 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 de id_token para um utilizador convidado no tenant.

{
  "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.

1. A partir do pedido:
   • Certifique-se de que o redirect_uri é publicado na chamada de ID do Microsoft Entra fornecida ao provedor de identidade externo.
   • Verifique se o client_id tem um valor atribuído ao ID do Microsoft Entra, como ABCD.
   • O provedor deve primeiro validar o id_token_hint que lhe é apresentado pelo Microsoft Entra ID.
2. Das alegações em id_token_hint:
   • Opcionalmente, eles podem fazer uma chamada para o Microsoft Graph para buscar outros detalhes sobre esse usuário. As declarações oid e tid no id_token_hint são úteis neste contexto. Para obter detalhes sobre as declarações fornecidas no id_token_hint, consulte Declarações de id_token_hint padrão.
3. Em seguida, realize qualquer outra atividade de autenticação para a qual o produto do provedor tenha sido criado.
4. 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 da resposta do fornecedor pelo Microsoft Entra ID

O provedor precisa enviar uma resposta ao redirect_uri. Os seguintes parâmetros devem ser fornecidos em caso de resposta bem-sucedida:

Parâmetro	Valor	Descrição
id_token (token de identificação)		O token emitido pelo provedor de identidade externo.
estado		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	Descrição
ISS		Emissor – deve corresponder ao emissor nos metadados de descoberta do provedor.
aud		Audiência – o ID do cliente Microsoft Entra ID. Consulte o 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.
submarino		Assunto – deve corresponder ao sub do id_token_hint enviado para iniciar esta requisição.
Nonce		O mesmo nonce que foi passado na requisição.
ACR		A ACR reivindica 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 deverá ser retornada. Para obter a lista de declarações, consulte Declarações acr suportadas.
RAM		As afirmações amr relacionadas ao método de autenticação utilizado. 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 suportadas de ACR

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.
conhecimento	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
rosto	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	Biometria com varredura de íris
OTP	Palavra-passe única
Pop	Prova de propriedade
retina	Biometria do exame de retina
SC	Cartão inteligente
mensagem de texto (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 os requisitos de MFA estejam atendidos para emitir um token com reivindicaçõ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	Tipo	Notas
rosto	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	Biometria com varredura de íris
OTP	Posse	Palavra-passe monouso
Pop	Posse	Prova de propriedade
retina	Inerência	Biometria do exame de retina
SC	Posse	Cartão inteligente
mensagem de texto (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	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, 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: A verificação da assinatura do token de ID externo do emissor 'https://sts.XXXXXXXXX.com/auth/realms/XXXXXXXXXmfa' falhou. 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 controlos personalizados de acesso condicional podem operar em paralelo enquanto os clientes se preparam e fazem a migração para os 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 do controle de concessão personalizado.

  Nota

  Os controles de concessão baseados nos pontos fortes de autenticação, incluindo a capacidade MFA integrada, não são satisfeitos pelo EAM. As políticas só devem ser configuradas com Exigir autenticação multifator. O suporte para EAMs com pontos fortes de autenticação virá mais tarde.

• 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 seguro de que a política que requer MFA é satisfeita pelo EAM, o administrador pode incluir todos os utilizadores necessários na política com a autorização de MFA, e a política configurada para controles personalizados pode ser alterada 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

• Especificação OAuth2.0 e OIDC

Glossário

Termo	Descrição
AMF	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).