Fluxos e cenários de aplicação do AD FS OpenID Connect/OAuth

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

Fluxo de subvenções implícito

Para aplicativos de página única (AngularJS, Ember.js, React.jse assim por diante), o AD FS oferece suporte ao fluxo de concessão implícito do OAuth 2.0. O fluxo implícito é descrito na especificação OAuth 2.0. Seu principal benefício é que ele permite que o aplicativo obtenha tokens do AD FS sem executar uma troca de credenciais do servidor de back-end. Este fluxo permite que a aplicação autentique o utilizador, mantenha a sessão e obtenha tokens para outras APIs da web dentro do código JavaScript do cliente. Há algumas considerações de segurança importantes a serem levadas em conta ao usar o fluxo implícito, especificamente em torno do cliente.

Se você quiser usar o fluxo implícito e o AD FS para adicionar autenticação ao seu aplicativo JavaScript, siga as etapas gerais na seção a seguir.

Diagrama de protocolo

O diagrama a seguir mostra a aparência de todo o fluxo de entrada implícito. As seções a seguir descrevem cada etapa com mais detalhes.

Solicitar um token de ID e um token de acesso

Para iniciar sessão do utilizador na sua aplicação, pode enviar um pedido de autenticação OpenID Connect e obter um id_token e um token de acesso a partir do ponto de extremidade do AD FS.

// Line breaks for legibility only

https://adfs.contoso.com/adfs/oauth2/authorize?
client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&response_type=id_token+token
&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F
&scope=openid
&response_mode=fragment
&state=12345

Neste ponto, o usuário é solicitado a inserir suas credenciais e concluir a autenticação. Depois que o utilizador se autentica, o ponto de extremidade de autorização do AD FS retorna uma resposta à sua aplicação na URI de redirecionamento indicada, usando o método especificado no parâmetro modo de resposta.

Resposta com êxito

Uma resposta bem-sucedida, quando response_mode=fragment and response_type=id_token+token usada, tem esta aparência:

// Line breaks for legibility only

GET https://localhost/myapp/#
access_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZEstZnl0aEV...
&token_type=Bearer
&expires_in=3599
&scope=openid
&id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZstZnl0aEV1Q...
&state=12345

Atualizar tokens

A concessão implícita não fornece tokens de atualização. Tanto id_tokens quanto access_tokens expiram após um curto período de tempo, portanto, seu aplicativo deve estar preparado para atualizar esses tokens periodicamente. Para atualizar qualquer tipo de token, você pode executar a mesma solicitação iframe oculta como na seção anterior, usando o prompt=none parâmetro para controlar o comportamento da plataforma de identidade. Se você quiser receber um novo id_token, certifique-se de usar response_type=id_token.

Fluxo de concessão do código de autorização

Você pode usar a concessão de código de autorização OAuth 2.0 em aplicativos Web para obter acesso a recursos protegidos, como APIs da Web. O fluxo de código de autorização do OAuth 2.0 é descrito na seção 4.1 da especificação do OAuth 2.0. Ele é usado para executar autenticação e autorização na maioria dos tipos de aplicativos, incluindo aplicativos Web e aplicativos instalados nativamente. O fluxo permite que os aplicativos adquiram com segurança access_tokens que podem ser usados para acessar recursos que confiam no AD FS.

Diagrama de protocolo

Em um alto nível, o fluxo de autenticação para um aplicativo nativo se parece um pouco com isto:

Solicitar um código de autorização

O fluxo de código de autorização começa com o cliente direcionando o utilizador para o endpoint /autorizar. Nessa solicitação, o cliente indica as permissões que precisa adquirir do usuário:

// Line breaks for legibility only

https://adfs.contoso.com/adfs/oauth2/authorize?
client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&response_type=code
&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F
&response_mode=query
&resource=https://webapi.com/
&scope=openid
&state=12345

Neste ponto, o usuário é solicitado a inserir suas credenciais e concluir a autenticação. Depois de o utilizador se autenticar, o AD FS retorna uma resposta à sua aplicação no redirect_uri indicado, usando o método especificado no parâmetro response_mode.

Resposta com êxito

Uma resposta bem-sucedida, quando response_mode=query é usada, tem esta aparência:

GET https://adfs.contoso.com/common/oauth2/nativeclient?
code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&state=12345

Solicitar um token de acesso

Agora que você adquiriu um authorization_code e recebeu permissão do usuário, pode resgatar o código do access_token para o recurso desejado. Resgate o código enviando uma solicitação POST para o ponto de extremidade /token:

// Line breaks for legibility only

POST /adfs/oauth2/token HTTP/1.1
Host: https://adfs.contoso.com/
Content-Type: application/x-www-form-urlencoded

client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&code=OAAABAAAAiL9Kn2Z27UubvWFPbm0gLWQJVzCTE9UkP3pSx1aXxUjq3n8b2JRLk4OxVXr...
&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F
&grant_type=authorization_code
&client_secret=JqQX2PNo9bpM0uEihUPzyrh    // NOTE: Only required for confidential clients (web apps)

Resposta com êxito

Uma resposta de token bem-sucedida tem esta aparência:

{
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
    "token_type": "Bearer",
    "expires_in": 3599,
    "refresh_token": "AwABAAAAvPM1KaPlrEqdFSBzjqfTGAMxZGUTdM0t4B4...",
    "refresh_token_expires_in": 28800,
    "id_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJub25lIn0.eyJhdWQiOiIyZDRkMTFhMi1mODE0LTQ2YTctOD...",
}

Usar o token de acesso

GET /v1.0/me/messages
Host: https://webapi.com
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...

Atualizar o fluxo de concessão de token

Access_tokens são de curta duração, e você deve atualizá-los depois que expirarem para continuar acessando recursos. Você pode fazer isso enviando outra solicitação POST para o endpoint /token, desta vez fornecendo o refresh_token em vez do código. Os tokens de atualização são válidos para todas as permissões para as quais seu cliente já recebeu tokens de acesso.

Os tokens de atualização não têm tempos de vida especificados. Normalmente, os tempos de vida dos tokens de atualização são relativamente longos. No entanto, em alguns casos, os tokens de atualização expiram, são revogados ou não têm privilégios suficientes para a ação desejada. A sua aplicação necessita esperar e tratar corretamente os erros retornados pelo endpoint de emissão de token.

Embora os tokens de atualização não sejam revogados quando usados para adquirir novos tokens de acesso, espera-se que você descarte o token de atualização antigo. A especificação OAuth 2.0 diz: "O servidor de autorização PODE emitir um novo token de atualização, caso em que o cliente DEVE descartar o token de atualização antigo e substituí-lo pelo novo token de atualização. O servidor de autorização PODE revogar o token de atualização antigo depois de emitir um novo token de atualização para o cliente." O AD FS emite tokens de atualização quando o tempo de vida do novo token de atualização é maior do que o tempo de vida do token de atualização anterior. Para exibir informações adicionais sobre os tempos de vida do token de atualização do AD FS, consulte Configurações de logon único do AD FS.

// Line breaks for legibility only

POST /adfs/oauth2/token HTTP/1.1
Host: https://adfs.contoso.com
Content-Type: application/x-www-form-urlencoded

client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&refresh_token=OAAABAAAAiL9Kn2Z27UubvWFPbm0gLWQJVzCTE9UkP3pSx1aXxUjq...
&grant_type=refresh_token
&client_secret=JqQX2PNo9bpM0uEihUPzyrh      // NOTE: Only required for confidential clients (web apps)

Resposta com êxito

Uma resposta de token bem-sucedida tem esta aparência:

{
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
    "token_type": "Bearer",
    "expires_in": 3599,
    "refresh_token": "AwABAAAAvPM1KaPlrEqdFSBzjqfTGAMxZGUTdM0t4B4...",
    "refresh_token_expires_in": 28800,
    "id_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJub25lIn0.eyJhdWQiOiIyZDRkMTFhMi1mODE0LTQ2YTctOD...",
}

Suporte de PKCE (Proof Key for Code Exchange) para OAuth

Os clientes públicos OAuth que usam a concessão de código de autorização são vulneráveis a ataques de intercetação de código de autorização, conforme descrito na RFC 7636. Para atenuar esses ataques, a partir do Windows Server 2019, o AD FS oferece suporte à PKCE (Proof Key for Code Exchange) para o fluxo de concessão de código de autorização OAuth.

A especificação de suporte PKCE adiciona mais parâmetros às solicitações de token de acesso e autorização OAuth 2.0. O diagrama a seguir mostra um esquema do processo PKCE quando um cliente contacta o AD FS no Windows Server 2019.

Na seção rotulada A, o cliente cria e registra um segredo chamado code_verifier e deriva uma versão transformada do segredo chamada t(code_verifier), também conhecida como code_challenge. Em seguida, o cliente envia o segredo na solicitação de autorização OAuth 2.0, juntamente com o método de transformação de t_m.

Na seção rotulada B, o endpoint de autorização responde habitualmente, mas registra o t(code_verifier) segredo e o método de transformação.

Na seção rotulada C, o cliente envia o código de autorização na solicitação de token de acesso como de costume, mas inclui o code_verifier segredo gerado na seção A.

Na seção rotulada D, AD FS transforma o code_verifiersegredo e o compara com o t(code_verifier) segredo da seção B. Se seus valores não forem iguais, o AD FS negará o acesso.

Como escolher vários provedores de autenticação para a mesma política de regra no Windows Server 2019

O AD FS já oferece suporte à ativação de autenticação extra com base numa política de regra de declaração de reivindicação (RP). Você pode definir essas políticas para um RP específico ou em um nível global. Você pode definir uma política de autenticação extra para um RP específico abrindo o PowerShell como administrador e executando o cmdlet Set-AdfsRelyingPartyTrust , passando o parâmetro AdditionalAuthenticationRules ou AdditionalAuthenticationRulesFile . Para defini-lo globalmente, um administrador pode usar o cmdlet Set-AdfsAdditionalAuthenticationRule . A definição de políticas adicionais permite que você use mais de um provedor de autenticação para o mesmo aplicativo.

As regras de declaração oferecem a opção de selecionar o provedor de autenticação para autenticação adicional, o que se mostra benéfico em situações em que os clientes estão mudando de provedor ou exigem um provedor distinto para determinados aplicativos. A partir do Windows Server 2019, você pode usar regras de declarações para decidir qual outro provedor de autenticação invocar para autenticação extra. Esse recurso é útil em dois cenários:

• Os usuários estão fazendo a transição de um provedor de autenticação para outro. À medida que você integra os usuários a um provedor de autenticação mais recente, eles podem usar grupos para controlar qual provedor de autenticação extra o serviço usa.

• Os usuários precisam de um provedor de autenticação extra específico para determinados aplicativos, mas também precisam usar um método diferente para outros aplicativos.

Você pode definir essas configurações executando o seguinte comando de outras políticas de autenticação:

Set-AdfsAdditionalAuthenticationRule -AdditionalAuthenticationRules 'c:[type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", value == "false"] => issue(type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", value = "http://schemas.microsoft.com/claims/multipleauthn" );' 

Para configurar essa regra, você deve emitir a declaração http://schemas.microsoft.com/claims/authnmethodsproviders de outras políticas de autenticação. O valor dessa declaração deve ser a variável Name do provedor de autenticação.

Você também pode modificar essa configuração de regra para ajudar os usuários a fazer a transição de um provedor de autenticação para outro. Por exemplo, digamos que você queira modificar um grupo que você gere para usar a autenticação multifator (MFA) do Microsoft Entra e outro grupo para usar certificados do Microsoft Entra como um provedor de autenticação extra.

Se quiser controlar quantas pessoas se registram para autenticação de MFA e certificado, você pode executar um comando como este, com os valores substituídos por valores relevantes para sua organização:

'c:[type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] => issue(type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn" ); 

 c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value == "S-1-5-21-608905689-872870963-3921916988-12345"] => issue(Type = "http://schemas.microsoft.com/claims/authnmethodsproviders", Value = "AzureMfaAuthentication"); 

not exists([Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value=="S-1-5-21-608905689-872870963-3921916988-12345"]) => issue(Type = "http://schemas.microsoft.com/claims/authnmethodsproviders", Value = "CertificateAuthentication");’ 

Em seguida, você pode definir o primeiro aplicativo, chamado AppA, para usar MFA como um provedor de autenticação extra executando este comando:

Set-AdfsRelyingPartyTrust -TargetName AppA -AdditionalAuthenticationRules 'c:[type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] => issue(type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn" ); 

c:[] => issue(Type = "http://schemas.microsoft.com/claims/authnmethodsproviders", Value = "AzureMfaAuthentication");' 

Finalmente, você pode definir o segundo aplicativo, chamado AppB, para usar certificados como um provedor de autenticação extra executando este comando:

Set-AdfsRelyingPartyTrust -TargetName AppB -AdditionalAuthenticationRules 'c:[type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] => issue(type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn" ); 

c:[] => issue(Type = "http://schemas.microsoft.com/claims/authnmethodsproviders", Value = "CertificateAuthentication");' 

Os administradores também podem criar regras para permitir mais de um provedor de autenticação extra. Nesse caso, o AD FS mostra os provedores de método de autenticação emitidos e um usuário pode escolher qualquer um deles. Para permitir vários provedores de autenticação extras, eles devem emitir várias declarações usando o valor http://schemas.microsoft.com/claims/authnmethodsproviders.

Se a avaliação da declaração não devolver nenhum dos provedores de autenticação, o AD FS reverte e exibe uma lista que mostra todos os provedores de autenticação adicionais configurados pelo administrador no AD FS. O usuário deve então selecionar manualmente o provedor de autenticação apropriado.

Se seu provedor de autenticação preferido não estiver na lista, você poderá executar o seguinte cmdlet para exibir todos os provedores suportados:

(Get-AdfsGlobalAuthenticationPolicy).AdditionalAuthenticationProvider

O valor usado para a http://schemas.microsoft.com/claims/authnmethodsproviders declaração deve ser um dos nomes de provedor retornados pela lista de provedores retornados pelo AD FS.

O AD FS não oferece suporte ao acionamento de um provedor de autenticação extra específico enquanto o RP estiver usando Políticas de Controle de Acesso no AD FS Windows Server 2016. Quando você move um aplicativo para fora de uma política de controle de acesso, o AD FS copia a política correspondente da Política de Controle de Acesso para AdditionalAuthenticationRules e IssuanceAuthorizationRules. Se um administrador quiser usar um provedor de autenticação específico, ele deve parar de usar a política de controle de acesso e, em vez disso, modificar AdditionalAuthenticationRules.

fluxo On-Behalf-Of

O OAuth 2.0 On-Behalf-Of flow (OBO) serve o caso de uso em que um aplicativo invoca um serviço/API da Web, que por sua vez precisa chamar outro serviço/API da Web. A ideia é propagar a identidade e as permissões do usuário delegado através da cadeia de solicitações. Para que o serviço de camada intermediária faça solicitações autenticadas para o serviço downstream, ele precisa proteger um token de acesso do AD FS, em nome do usuário.

Diagrama de protocolo

Suponha que um usuário é autenticado em um aplicativo usando o fluxo de concessão de código de autorização OAuth 2.0 descrito na seção anterior. Neste ponto, o aplicativo tem um token de acesso para a API A (token A) com as declarações do usuário e consentimento para acessar a API da Web de camada intermediária (API A). Certifique-se de que o cliente solicita o escopo user_impersonation no token. Agora, a API A precisa fazer uma solicitação autenticada para a API da Web downstream (API B).

Os passos que se seguem constituem o fluxo OBO e são explicados com a ajuda do diagrama seguinte.

1. O aplicativo cliente faz uma solicitação à API A com o token A. (Ao configurar o fluxo OBO no AD FS, verifique se o escopo user_impersonation está selecionado e se os clientes solicitam user_impersonation o escopo na solicitação.)
2. A API A autentica no ponto de extremidade de emissão de token do AD FS e solicita um token para acessar a API B. (Ao configurar esse fluxo no AD FS, verifique se a API A também está registrada como um aplicativo de servidor com uma ID de cliente que tenha o mesmo valor que a ID de recurso na API A.)
3. O ponto de extremidade de emissão de token do AD FS valida as credenciais da API A com o token A e emite o token de acesso para a API B (token B).
4. O token B é definido no cabeçalho de autorização da solicitação para a API B.
5. Os dados do recurso protegido são retornados pela API B.

Solicitação de token de acesso entre serviços

Para solicitar um token de acesso, faça um HTTP POST para o ponto de extremidade do token do AD FS com os parâmetros descritos nas seções a seguir.

Primeiro caso: Solicitação de token de acesso com um segredo compartilhado

Para um segredo compartilhado, uma solicitação de token de acesso de serviço a serviço contém os seguintes parâmetros:

Example

O seguinte HTTP POST solicita um token de acesso e um token de atualização.

// Line breaks for legibility only

POST /adfs/oauth2/token HTTP/1.1
Host: adfs.contoso.com
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer
&client_id=https://webapi.com/
&client_secret=BYyVnAt56JpLwUcyo47XODd
&assertion=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIm…
&resource=https://secondwebapi.com/
&requested_token_use=on_behalf_of
&scope=openid

Segundo caso: Solicitação de token de acesso com um certificado

Uma solicitação de token de acesso serviço a serviço com um certificado contém os seguintes parâmetros:

Observe que os parâmetros são quase os mesmos. Este exemplo é semelhante à solicitação por segredo compartilhado, exceto que o parâmetro client_secret é substituído por dois parâmetros: client_assertion_type e client_assertion.

Example

O HTTP POST a seguir solicita um token de acesso para a API da Web com um certificado.

// Line breaks for legibility only

POST /adfs/oauth2/token HTTP/1.1
Host: https://adfs.contoso.com
Content-Type: application/x-www-form-urlencoded

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer
&client_id= https://webapi.com/
&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer
&client_assertion=eyJhbGciOiJSUzI1NiIsIng1dCI6Imd4OHRHeXN5amNS…
&resource=https://secondwebapi.com/
&requested_token_use=on_behalf_of
&scope= openid

Resposta de token de acesso de serviço a serviço

Uma resposta bem-sucedida é uma resposta JSON OAuth 2.0 que tem os seguintes parâmetros.

Exemplo de resposta bem-sucedida

O exemplo a seguir mostra uma resposta bem-sucedida a uma solicitação de um token de acesso para a API da Web.

{
  "token_type": "Bearer",
  "scope": openid,
  "expires_in": 3269,
  "access_token": "eyJ0eXAiOiJKV1QiLCJub25jZSI6IkFRQUJBQUFBQUFCbmZpRy1t"
  "id_token": "aWRfdG9rZW49ZXlKMGVYQWlPaUpLVjFRaUxDSmhiR2NpT2lKU1V6STFOa"
  "refresh_token": "OAQABAAAAAABnfiG…"
  "refresh_token_expires_in": 28800,
}

Use o token de acesso para acessar o recurso seguro

Agora, o serviço de camada intermediária pode usar o token adquirido no exemplo de resposta anterior para fazer solicitações autenticadas para a API da Web downstream. Defina o token no cabeçalho Autorização.

Example

GET /v1.0/me HTTP/1.1
Host: https://secondwebapi.com
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJub25jZSI6IkFRQUJBQUFBQUFCbmZpRy1tQ…

Fluxo de concessão de credenciais do cliente

Você pode usar a concessão de credenciais de cliente OAuth 2.0 especificada no RFC 6749 para acessar recursos hospedados na Web usando a identidade de um aplicativo. Esse tipo de concessão é comumente usado para interações de servidor para servidor que devem ser executadas em segundo plano, sem interação imediata com um usuário. Estes tipos de aplicações são frequentemente denominados daemons ou conta de serviço.

O fluxo de concessão de credenciais do cliente OAuth 2.0 permite que um serviço Web (cliente confidencial) use suas próprias credenciais, em vez de representar um usuário, para autenticar ao chamar outro serviço Web. Nesse cenário, o cliente normalmente é um serviço Web de camada intermediária, um serviço daemon ou um site. Para um nível mais alto de garantia, o AD FS também permite que o serviço de chamada use um certificado (em vez de um segredo compartilhado) como credencial.

Diagrama de protocolo

O diagrama a seguir mostra o fluxo de concessão de credenciais do cliente.

Solicite um token

Para obter um token usando a concessão de credenciais do cliente, envie uma POST solicitação para o endpoint /token do AD FS, conforme mostrado nas seções a seguir.

Primeiro caso: Solicitação de token de acesso com um segredo compartilhado

POST /adfs/oauth2/token HTTP/1.1
// Line breaks for legibility only

Host: https://adfs.contoso.com
Content-Type: application/x-www-form-urlencoded

client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&client_secret=qWgdYAmab0YSkuL1qKv5bPX
&grant_type=client_credentials

Segundo caso: Solicitação de token de acesso com um certificado

POST /adfs/oauth2/token HTTP/1.1

// Line breaks for legibility only

Host: https://adfs.contoso.com
Content-Type: application/x-www-form-urlencoded

&client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer
&client_assertion=eyJhbGciOiJSUzI1NiIsIng1dCI6Imd4OHRHeXN5amNScUtqRlBuZDdSRnd2d1pJMCJ9.eyJ{a lot of characters here}M8U3bSUKKJDEg
&grant_type=client_credentials

Usar um token

Agora que você adquiriu um token, use-o para fazer solicitações ao recurso. Quando o token expirar, repita a solicitação para o endpoint /token para adquirir um novo token de acesso.

GET /v1.0/me/messages
Host: https://webapi.com
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...

Fluxo de concessão de credenciais de senha do proprietário do recurso (não recomendado)

A concessão de credenciais de senha do proprietário do recurso (ROPC) permite que uma aplicação autentique diretamente o utilizador manipulando sua senha. O fluxo ROPC requer um alto grau de confiança e exposição do usuário. Você deve usar esse fluxo somente quando não puder usar outros fluxos mais seguros.

Diagrama de protocolo

O diagrama a seguir mostra o fluxo ROPC.

Pedido de autorização

O fluxo ROPC é uma única solicitação — ele envia a identificação do cliente e as credenciais do usuário para o IDP e, em seguida, recebe tokens em troca. O cliente deve solicitar o endereço de e-mail (UPN) e a senha do usuário antes de fazê-lo. Imediatamente após uma solicitação bem-sucedida, o cliente deve liberar com segurança as credenciais do usuário da memória. Não deve nunca salvá-los.

// Line breaks and spaces are for legibility only

POST /adfs/oauth2/token HTTP/1.1
Host: https://adfs.contoso.com
Content-Type: application/x-www-form-urlencoded

client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&scope= openid
&username=myusername@contoso.com
&password=SuperS3cret
&grant_type=password

Resposta de autenticação bem-sucedida

O exemplo seguinte mostra uma resposta de token bem-sucedida:

{
    "token_type": "Bearer",
    "scope": "openid",
    "expires_in": 3599,
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIn...",
    "refresh_token": "AwABAAAAvPM1KaPlrEqdFSBzjqfTGAMxZGUTdM0t4B4...",
    "refresh_token_expires_in": 28800,
    "id_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJub25lIn0.eyJhdWQiOiIyZDR..."
}

Você pode usar o token de atualização para adquirir novos tokens de acesso e tokens de atualização usando o mesmo fluxo descrito na seção de fluxo de concessão de código de autenticação deste artigo.

Fluxo de código do dispositivo

A concessão de código de dispositivo permite que os usuários entrem em dispositivos com restrição de entrada, como uma smart TV, dispositivo IoT ou impressora. Para habilitar esse fluxo, o dispositivo faz com que o usuário visite uma página da Web em seu navegador em outro dispositivo para entrar. Depois que o usuário faz login, o dispositivo é capaz de obter tokens de acesso e atualizar tokens conforme necessário.

Diagrama de protocolo

Todo o fluxo de código do dispositivo é semelhante ao fluxo mostrado no diagrama seguinte. Cada uma das etapas é descrita mais adiante neste artigo.

Pedido de autorização do dispositivo

O cliente deve primeiro verificar com o servidor de autenticação se há um dispositivo e código de usuário usado para iniciar a autenticação. O cliente recolhe este pedido do /devicecode endpoint. Nessa solicitação, o cliente também deve incluir as permissões que precisa adquirir do usuário. A partir do momento em que esta solicitação é enviada, o usuário tem apenas 15 minutos para entrar (o valor habitual para expires_in), portanto, só faça essa solicitação quando o usuário tiver indicado que está pronto para entrar.

// Line breaks are for legibility only

POST https://adfs.contoso.com/adfs/oauth2/devicecode
Content-Type: application/x-www-form-urlencoded

client_id=00001111-aaaa-2222-bbbb-3333cccc4444
scope=openid

Resposta de autorização do dispositivo

Uma resposta bem-sucedida é um objeto JSON que contém as informações necessárias para permitir que o usuário faça login.

Autenticando o usuário

Depois que o cliente recebe o user_code e verification_uri, ele exibe esses detalhes para o usuário, instruindo-o a entrar usando o navegador do celular ou do PC. Além disso, o cliente pode usar um código QR ou mecanismo semelhante para exibir o verification_uri_complete, que elimina a etapa de inserir o código do utilizador pelo usuário. Enquanto o utilizador está a autenticar-se no verification_uri, o cliente deve interrogar o /token endpoint pelo token solicitado usando o código do dispositivo.

POST https://adfs.contoso.com /adfs/oauth2/token
Content-Type: application/x-www-form-urlencoded

grant_type: urn:ietf:params:oauth:grant-type:device_code
client_id: 00001111-aaaa-2222-bbbb-3333cccc4444
device_code: GMMhmHCXhWEzkobqIHGG_EnNYYsAkukHspeYUk9E8

Resposta de autenticação bem-sucedida

Uma resposta de token bem-sucedida pode incluir estes parâmetros:

Conteúdo relacionado

Consulte Desenvolvimento do AD FS para obter a lista completa de artigos passo a passo, que fornecem instruções passo a passo sobre como usar os fluxos relacionados.