Fluxos e cenários de aplicativo do AD FS OpenID Connect/OAuth

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

Fluxo de concessão implícita

Para aplicativos de página única (AngularJS, Ember.js, React.jse assim por diante), o AD FS dá suporte ao fluxo de concessão implícita do OAuth 2.0. O fluxo implícito é descrito na especificação OAuth 2.0. O principal benefício é que ele permite que o aplicativo obtenha tokens do AD FS sem executar uma troca de credenciais de servidor de back-end. Esse fluxo permite que o aplicativo se conecte ao usuário, mantenha a sessão e obtenha tokens para outras APIs Web no código JavaScript do cliente. Há algumas considerações de segurança importantes a serem consideradas ao usar o fluxo implícito, especificamente em torno do cliente.

Caso queira usar o fluxo implícito e 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ícita. As seções a seguir descrevem cada etapa com mais detalhes.

Solicitar um token de ID e um token de acesso

Para inicialmente conectar o usuário ao seu aplicativo, você pode enviar uma solicitação de autenticação do OpenID Connect e obter um token de id_token e acesso 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

Nesse ponto, é solicitado que o usuário insira suas credenciais e conclua a autenticação. Após a autenticação do usuário, o ponto de extremidade de autorização do AD FS retorna uma resposta ao seu aplicativo no redirect_uri indicado, usando o método especificado no parâmetro response_mode.

Resposta bem-sucedida

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 de código de autorização

Você pode usar a concessão de código de autorização do OAuth 2.0 em aplicativos Web para obter acesso a recursos protegidos, como APIs Web. O fluxo do 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 access_tokens com segurança 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 é um pouco parecido com isto:

Solicitar um código de autorização

O fluxo do código de autorização começa com o cliente direcionando o usuário para o ponto de extremidade /authorize. 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

Nesse ponto, é solicitado que o usuário insira suas credenciais e conclua a autenticação. Após a autenticação do usuário, o AD FS retorna uma resposta ao seu aplicativo no indicado redirect_uri, usando o método especificado no response_mode parâmetro.

Resposta bem-sucedida

Uma resposta bem-sucedida, quando response_mode=consulta é 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 pelo usuário, pode resgatar o código de um 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 bem-sucedida

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 têm vida curta e você deve atualizá-los depois que eles expirarem para continuar acessando os recursos. Você pode fazer isso enviando outra solicitação POST para o ponto de extremidade /token, desta vez, fornecendo refresh_token em vez do código. Os tokens de atualização são válidos para todas as permissões para as quais o cliente já recebeu tokens de acesso.

Os tokens de atualização não têm tempos de vida especificados. Normalmente, os tempos de vida de 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. Seu aplicativo precisa esperar e tratar os erros retornados pelo ponto de extremidade de emissão de token corretamente.

Embora os tokens de atualização não sejam revogados quando usados para adquirir novos tokens de acesso, 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, nesse caso, 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 anterior do token de atualização. Para exibir informações adicionais sobre os tempos de vida do token de atualização do AD FS, consulte as 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 bem-sucedida

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 (Chave de Prova para Troca de Código) 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 interceptação de código de autorização, conforme descrito no RFC 7636. Para atenuar esses ataques, a partir do Windows Server 2019, o AD FS dá suporte à Chave de Prova para Troca de Códigos (PKCE) para o fluxo de concessão de código de autorização OAuth.

A especificação de suporte do PKCE adiciona mais parâmetros às solicitações de token de acesso e autorização do OAuth 2.0. O diagrama a seguir mostra uma estrutura de tópicos do processo PKCE quando um cliente entra em contato com 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 do OAuth 2.0 junto com o método de t_m transformação.

Na seção rotulada B, o ponto de extremidade de autorização responde como de costume, 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, o AD FS transforma o code_verifiersegredo e o compara ao t(code_verifier) segredo da seção B. Se seus valores não forem iguais, o AD FS negará acesso.

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

O AD FS já é compatível com um disparo de autenticação adicional baseado na política de regra de declaraçã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 configuração de políticas extras permite que você use mais de um provedor de autenticação para o mesmo aplicativo.

As regras de declaração fornecem 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 alternando entre provedores 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ê deverá 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ê gerencia para usar a MFA (autenticação multifator) do Microsoft Entra e um grupo para usar certificados como um provedor de autenticação extra.

Se você quiser acompanhar quantas pessoas se registram para mfa e autenticação de 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 a 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");' 

Por fim, 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 fazer regras para permitir mais de um provedor de autenticação adicional. 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 extra, eles devem emitir várias declarações usando o valor http://schemas.microsoft.com/claims/authnmethodsproviders.

Se a avaliação de declaração não retornar nenhum dos provedores de autenticação, o AD FS será revertido e exibirá uma lista mostrando todos os provedores de autenticação extras configurados pelo administrador no AD FS. Em seguida, o usuário deve selecionar manualmente o provedor de autenticação apropriado.

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

(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 disparo de um provedor de autenticação extra específico enquanto o RP está 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 deverá parar de usar a política de controle de acesso e, em vez disso, modificar AdditionalAuthenticationRules.

fluxo On-Behalf-Of

O fluxo OBO (On-Behalf-Of) do OAuth 2.0 atende ao caso de uso em que um aplicativo invoca uma API de serviço/Web que, por sua vez, precisa chamar outra API de serviço/Web. A ideia é propagar a identidade do usuário delegado e as permissões pela cadeia de solicitação. 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 seja 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 o consentimento para acessar a API Web de nível intermediário (API A). Verifique se as solicitações do cliente user_impersonation escopo no token. Agora, a API A precisa fazer uma solicitação autenticada para a API Web downstream (API B).

As etapas a seguir constituem o fluxo OBO e são explicadas com a ajuda do diagrama a seguir.

1. O aplicativo cliente faz uma solicitação à API A com o token A. (Quando você configura 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-se 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 do recurso na API A.)
3. O ponto de extremidade de emissão de token 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 de serviço a serviço

Para solicitar um token de acesso, faça um HTTP POST no ponto de extremidade de 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 de 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 pelo fato de 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 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 do token de acesso serviço a serviço

Uma resposta de êxito é uma resposta JSON OAuth 2.0 que tem os seguintes parâmetros.

Exemplo de resposta de sucesso

O exemplo a seguir mostra uma resposta de sucesso a uma solicitação de um token de acesso para a API Web.

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

Usar o token de acesso para acessar o recurso protegido

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 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 de cliente

Você pode usar a concessão de credenciais de cliente do OAuth 2.0 especificada no RFC 6749 para acessar recursos hospedados na Web usando a identidade de um aplicativo. Esse tipo de concessão normalmente é usado para interações de servidor para servidor que devem ser executadas em segundo plano, sem interação imediata com um usuário. Esses tipos de aplicativo normalmente são chamados de daemons ou contas 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 nível intermediário, um serviço de daemon ou um site da Web. 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 uma credencial.

Diagrama de protocolo

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

Solicitar um token

Para obter um token usando a concessão de credenciais do cliente, envie uma POST solicitação para o ponto de extremidade /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 para o recurso. Quando o token expirar, repita a solicitação para o ponto de extremidade /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 ROPC (credencial de senha de proprietário do recurso) permite que um aplicativo conecte o usuário processando a senha dele diretamente. 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 do ROPC.

Solicitação de autorização

O fluxo ROPC é uma solicitação — ele envia a identificação do cliente e as credenciais do usuário para o IDP e, em seguida, recebe tokens em retorno. O cliente deve solicitar o endereço de email (UPN) do usuário e a senha antes de fazer isso. Imediatamente após uma solicitação bem-sucedida, o cliente deve liberar com segurança as credenciais do usuário da memória. Ele nunca deve 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 abaixo 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 atualizar tokens 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ções de entrada, como uma TV inteligente, um dispositivo IoT ou uma impressora. Para habilitar esse fluxo, o dispositivo faz o usuário acessar uma página da Web em seu navegador em outro dispositivo para entrar. Depois que o usuário entrar, o dispositivo poderá 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 próximo diagrama. Cada uma das etapas é descrita posteriormente neste artigo.

Solicitação de autorização do dispositivo

O cliente deve primeiro verificar o servidor de autenticação para obter um código de usuário e de dispositivo usado para iniciar a autenticação. O cliente coleta essa solicitação do ponto de extremidade /devicecode. Nessa solicitação, o cliente também deve incluir as permissões que precisa adquirir do usuário. A partir do momento em que essa solicitação é enviada, o usuário tem apenas 15 minutos para entrar (o valor usual para expires_in), portanto, faça essa solicitação somente quando o usuário indicar 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 entre.

Como autenticar 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 seu telefone celular ou navegador do computador. Além disso, o cliente pode usar um código QR ou um mecanismo semelhante para exibir verification_uri_complete, que leva à etapa de inserir o user_code para o usuário. Enquanto o usuário estiver se autenticando no verification_uri, o cliente deverá sondar o ponto de extremidade /token para obter o token solicitado usando o device_code.

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

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