Partilhar via


Conceitos do AD FS OpenID Connect/OAuth

Aplica-se aos Serviços de Federação do Active Directory (AD FS) 2016 e posteriores

Atores de autenticação modernos

Actor Description
Utilizador final A entidade de segurança (utilizadores, aplicações, serviços e grupos) que acede ao recurso.
Client A sua aplicação Web, identificada pelo respetivo ID de cliente. O cliente geralmente é a parte com a qual o usuário final interage e o cliente solicita tokens do servidor de autorização.
Servidor de autorização/provedor de identidade (IdP) O servidor AD FS. É responsável por verificar a identidade das entidades de segurança existentes no diretório de uma organização. Ele emite tokens de segurança (token de acesso do portador, token de ID e token de atualização) após a autenticação dessas entidades de segurança com sucesso.
Servidor de recursos/Provedor de recursos/Terceira parte confiável Onde reside o recurso ou os dados. Ele confia no servidor de autorização para autenticar e autorizar o cliente com segurança e usa tokens de acesso portador para garantir que o acesso a um recurso possa ser concedido.

O diagrama a seguir fornece a relação mais básica entre os atores:

Diagrama dos atores de autenticação modernos.

Tipos de aplicação

Tipo de Aplicação Description Role
Aplicação nativa Às vezes chamado de cliente público. Destina-se a ser um aplicativo cliente que é executado em um PC ou dispositivo e com o qual o usuário interage. Solicita tokens do servidor de autorização (AD FS) para acesso do usuário aos recursos. Envia solicitações HTTP para recursos protegidos, usando os tokens como cabeçalhos HTTP.
Aplicação de servidor (aplicação Web) Uma aplicação Web que é executada num servidor e acessível aos utilizadores através de um navegador. Por ser capaz de manter seu próprio segredo ou credencial de cliente, às vezes é chamado de cliente confidencial. Solicita tokens do servidor de autorização (AD FS) para acesso do usuário aos recursos. Antes de solicitar um token, o cliente (aplicativo Web) precisa se autenticar usando seu segredo.
API Web O recurso final que o usuário acessa. Pense nisso como a nova representação das partes dependentes. Consome tokens de acesso de portador obtidos pelos clientes.

Grupo de aplicação

Você deve associar um grupo de aplicativos a cada cliente OAuth nativo ou aplicativo Web ou recurso de API da Web configurado com o AD FS. Configure os clientes em um grupo de aplicativos para acessar os recursos no mesmo grupo. Um grupo de aplicativos pode ter vários clientes e recursos.

Fichas de segurança

A autenticação moderna usa os seguintes tipos de token:

  • id_token: Um token JWT emitido pelo servidor de autorização (AD FS) e consumido pelo cliente. As declarações no token de ID contêm informações sobre o usuário para que o cliente possa usá-lo.
  • access_token: Um token JWT emitido pelo servidor de autorização (AD FS) e destinado a ser consumido pelo recurso. A declaração 'aud' ou audience desse token deve corresponder ao identificador do recurso ou da API da Web.
  • refresh_token: Emitido pelo AD FS para o cliente usar quando precisar atualizar o id_token e o access_token. O token é opaco para o cliente e só é consumido pelo AD FS.

Atualizar tempos de vida do token

  • Logon simples, sem KMSI, dispositivo não registado: o AD FS aplica-se a SsoLifetime e DeviceUsageWindowInDays. O primeiro token de atualização tem lifetime=DeviceUsageWindowInDays ou SsoLifetime, com base em qual campo é menor, mas nenhum outro token de atualização é emitido.
  • logon KMSI, EnableKmsi=true no AD FS conf e kmsi=true passado como parâmetro: AD FS se aplica KmsiLifetimeMins com DeviceUsageWindowInDays. O primeiro token de atualização tem lifetime=DeviceUsageWindowInDays e recebe um novo token de atualização a cada solicitação de grant_type=refresh_token subsequente. Esse processo acontece apenas com clientes nativos ou cliente confidencial mais autenticação de dispositivo.
  • Dispositivos registados, autenticação de dispositivo: o AD FS usa PersistentSsoLifetimeMins e DeviceUsageWindowInDays semelhantes ao KMSI. Clientes nativos e confidenciais devem receber novos tokens de atualização, com base na autenticação do dispositivo.

Para saber mais, consulte documentação de logon único do AD FS.

Scopes

Ao registrar um recurso no AD FS, você pode configurar escopos para permitir que o AD FS execute ações específicas. Além de configurar o escopo, você deve enviar o valor do escopo na solicitação para que o AD FS execute a ação. Por exemplo, um administrador configura o escopo como openid durante o registro de recursos e o aplicativo (cliente) deve enviar o scope = openid na solicitação de autenticação para que o AD FS emita o Token de ID. A seguir estão os detalhes sobre os escopos disponíveis no AD FS:

  • aza - Se você usar extensões de protocolo OAuth 2.0 para clientes de broker e se o parâmetro scope contiver o escopo aza, o servidor emitirá um novo token de atualização primário. Ele define o token no campo refresh_token da resposta e define o refresh_token_expires_in field para o tempo de vida do novo token de atualização primário, se um for imposto.
  • openid - Permite que o aplicativo solicite o uso do protocolo de autenticação openid connect.
  • logon_cert - Permite que um aplicativo solicite certificados de entrada que você pode usar para fazer logon interativamente em usuários autenticados. O servidor AD FS omite o parâmetro access_token da resposta e, em vez disso, fornece uma cadeia de certificados CMS codificada em base64 ou uma resposta PKI completa CMC. Para obter mais informações, consulte as extensões do protocolo OAuth 2.0 em MS-OAPX.
  • user_impersonation - Solicita um token de acesso em nome de outrem através do AD FS. Para obter detalhes sobre como usar esse escopo, consulte Criar um aplicativo de várias camadas usandoBehalf-Of (OBO) usando OAuth com AD FS 2016.
  • allatclaims – Permite que o aplicativo solicite que as declarações no token de acesso também sejam adicionadas ao token de ID.
  • vpn_cert - Permite que um aplicativo solicite certificados VPN, que estabelecem conexões VPN usando autenticação EAP-TLS. Este recurso não é mais suportado.
  • email - Permite que o aplicativo solicite uma declaração de e-mail para o usuário conectado.
  • profile - Permite que o aplicativo solicite declarações relacionadas ao perfil para o usuário conectado.

Claims

Os tokens de segurança (tokens de acesso e ID) emitidos pelo AD FS contêm declarações ou afirmações de informações sobre o assunto que foi autenticado. Os aplicativos podem usar declarações para várias tarefas, incluindo:

  • Validar o token
  • Identificar o inquilino do diretório do sujeito
  • Exibir informações do usuário
  • Determinar a autorização do sujeito do ensaio

As declarações presentes em qualquer token de segurança dependem do tipo de token, do tipo de credencial usada para autenticar o usuário e da configuração do aplicativo.

Fluxo de autenticação de alto nível do AD FS

Segue-se um diagrama do fluxo de alto nível.

Diagrama do fluxo de autenticação do AD FS.

  1. O AD FS recebe solicitação de autenticação do cliente.

  2. O AD FS valida a ID do cliente na solicitação de autenticação com a ID do cliente obtida durante o registro do cliente e do recurso no AD FS. Se estiver usando um cliente confidencial, o AD FS também validará o segredo do cliente fornecido na solicitação de autenticação. O AD FS também valida o URI de redirecionamento do Cliente.

  3. O AD FS identifica o recurso que o cliente deseja acessar por meio do parâmetro resource passado na solicitação de autenticação. Se você usar a biblioteca de cliente MSAL, o parâmetro resource não será enviado. Em vez disso, a URL do recurso é enviada como parte do parâmetro scope: scope = [resource url]/[scope values, por exemplo, openid].

    Se o recurso não for passado usando os parâmetros de recurso ou escopo, o AD FS usará um recurso padrão urn:microsoft:userinfo cujas políticas, tais como MFA, emissão ou autorização, não podem ser configuradas.

  4. Em seguida, o AD FS valida se o cliente tem permissões para acessar o recurso. O AD FS também valida se os escopos passados na solicitação de autenticação correspondem aos escopos configurados durante o registro do recurso. Se o cliente não tiver as permissões ou os escopos corretos não forem enviados na solicitação de autenticação, o fluxo de autenticação será encerrado.

  5. Depois que as permissões e os escopos são validados, o AD FS autentica o usuário usando o método de autenticação configurado.

  6. Se outro método de autenticação for necessário de acordo com a política de recursos ou a política de autenticação global, o AD FS acionará a autenticação extra.

  7. O AD FS usa de autenticação multifator do Microsoft Entra ou de autenticação multifator de terceiros para fazer a autenticação.

  8. Depois que o usuário é autenticado, o AD FS aplica as regras de declaração. As regras de reivindicação determinam as reivindicações enviadas ao recurso como parte dos tokens de segurança. O AD FS também aplica as políticas de controle de acesso que confirmam que o usuário atende às condições necessárias para acessar o recurso.

  9. Em seguida, o AD FS gera o acesso e atualiza os tokens. O AD FS também gera o token de ID.

  10. O AD FS recebe a solicitação de autenticação.

  11. Se você incluir o scope = allatclaims na solicitação de autenticação, ele personalizará o token de ID para incluir declarações no token de acesso com base nas regras de declaração definidas.

  12. Depois que os tokens necessários são gerados e personalizados, o AD FS responde ao cliente e inclui os tokens. A resposta do token de ID só será incluída na resposta se a solicitação de autenticação incluir scope = openid. O cliente pode sempre obter o token de ID, após a autenticação, usando o endpoint do token.

Tipos de bibliotecas

Use dois tipos de bibliotecas com o AD FS:

  • Bibliotecas de cliente: clientes nativos e aplicativos de servidor usam bibliotecas de cliente para obter tokens de acesso para chamar um recurso, como uma API da Web. A Biblioteca de Autenticação da Microsoft (MSAL) é a biblioteca de cliente mais recente e recomendada quando você usa o AD FS 2019.

  • Bibliotecas de middleware do servidor : As aplicações Web usam bibliotecas de middleware de servidor para início de sessão do utilizador. As APIs da Web usam bibliotecas de middleware de servidor para validar tokens enviados por clientes nativos ou por outros servidores. Open Web Interface for .NET (OWIN) é a biblioteca de middleware recomendada.

Personalizar token de identificação (afirmações extras no token de identificação)

Em determinados cenários, é possível que o cliente do aplicativo Web precise de declarações extras em um token de ID para ajudar na funcionalidade. Configure declarações extras em um token de ID usando uma das seguintes opções:

Opção 1: Use essa opção quando tiver um cliente público e o aplicativo Web não tiver um recurso que esteja tentando acessar. Esta opção requer:

  • response_mode é definido como form_post
  • O identificador da terceira parte confiável (identificador da API da Web) é o mesmo que o identificador do cliente

Diagrama da opção de personalização de token um do AD FS.

Opção 2: Use essa opção quando o aplicativo Web tiver um recurso que está tentando acessar e precisar passar declarações extras por meio do token de ID. Você pode usar clientes públicos e confidenciais. Esta opção requer:

  • response_mode é definido como form_post

  • KB4019472 está instalado nos servidores AD FS

  • O escopo allatclaims é atribuído ao par cliente-RP. Você pode atribuir o escopo usando o Grant-ADFSApplicationPermission. Use Set-AdfsApplicationPermission se já tiver sido concedido uma vez. O cmdlet do PowerShell é indicado no exemplo a seguir:

    Grant-AdfsApplicationPermission -ClientRoleIdentifier "https://my/privateclient" -ServerRoleIdentifier "https://rp/fedpassive" -ScopeNames "allatclaims","openid"
    

Diagrama da opção dois de personalização de token do AD FS.

Para entender melhor como configurar um aplicativo Web no AD FS para obter um token de ID personalizado, consulte Tokens de ID personalizados no AD FS 2016 ou posterior.

Saída única

O logout único termina todas as sessões do cliente que usam o ID da sessão. AD FS 2016 e versões posteriores dispõem de suporte para terminação de sessão única com OpenID Connect/OAuth. Para obter mais informações, consulte Logon único para OpenID Connect com AD FS.

Pontos finais do AD FS

Ponto de extremidade do AD FS Description
/authorize O AD FS retorna um código de autorização que você pode usar para obter o token de acesso.
/token O AD FS retorna um token de acesso que você pode usar para acessar o recurso, como na API da Web.
/userinfo O AD FS retorna a reivindicação de assunto.
/devicecode O AD FS retorna o código do dispositivo e o código do usuário.
/logout O AD FS efetua logout do usuário.
/keys Chaves públicas do AD FS usadas para assinar respostas.
/.well-known/openid-configuration O AD FS retorna metadados OAuth/OpenID Connect.