Partilhar via

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

Aplica-se ao AD FS 2019 e versões posteriores

Cenário Passo a passo do cenário usando exemplos OAuth 2.0 Fluxo/Concessão Tipo de Cliente
Aplicação de página única Amostra usando MSAL implícito Público
Aplicação Web que autentica utilizadores Amostra usando OWIN Código de Autorização Público, Confidencial
Aplicativo nativo chama API da Web Amostra usando MSAL Código de Autorização Público
Aplicativo Web chama API Web Amostra usando MSAL Código de Autorização Confidencial
Implementação PKCE Código de Autorização Público
A Web API chama outra Web API em representação do usuário (OBO) Amostra usando MSAL Em nome de O aplicativo Web atua como Confidencial
Daemon App chama API Web Credenciais de cliente Confidencial
O Aplicativo Web chama a API da Web usando credenciais de usuário Credenciais de senha do proprietário do recurso Público, Confidencial
O aplicativo sem navegador chama a API da Web Código do dispositivo Público, confidencial

Fluxo de subvenções implícito

Observação

A Microsoft recomenda vivamente migrar para o Microsoft Entra ID em vez de atualizar para uma versão mais recente do AD FS. Para obter mais informações sobre o fluxo de concessão implícito no Microsoft Entra ID, consulte Fluxo de concessão implícito na plataforma de identidade da Microsoft.

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ícita 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 e as seções a seguir descrevem cada etapa com mais detalhes.

Início de sessão implícito

Solicitar Token de ID e Token de Acesso

Para iniciar a sessão do utilizador na sua aplicação, pode enviar um pedido de autenticação através do OpenID Connect e obter o id_token e o 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
Parâmetro Obrigatório/Opcional Descrição
ID do cliente obrigatório A ID do Aplicativo (cliente) que o AD FS atribuiu ao seu aplicativo.
tipo_de_resposta obrigatório Deve incluir id_token para login no OpenID Connect. Pode também incluir o response_type token. Usar o token aqui permite que a sua aplicação receba um token de acesso imediatamente a partir do endereço de autorização, sem ter que fazer uma segunda solicitação ao endereço do token.
uri_de_redirecionamento obrigatório O redirect_uri da sua aplicação, onde as respostas de autenticação podem ser enviadas e recebidas pela sua aplicação. Ele deve corresponder exatamente a um dos redirect_uris que você configurou no AD FS.
nonce obrigatório Um valor incluído na solicitação, gerado pelo aplicativo que deve ser incluído no id_token resultante como uma declaração. O aplicativo pode verificar esse valor para mitigar ataques de repetição de token. O valor é normalmente uma cadeia de caracteres aleatória e exclusiva que pode ser usada para identificar a origem da solicitação. Necessário apenas quando uma id_token é solicitada.
Âmbito de aplicação opcional Uma lista de escopos separados por espaço. Para o OpenID Connect, ele deve incluir o escopo openid.
recurso opcional A url da sua API Web.
Observação – Se estiver usando 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 e.g., openid]
Se o recurso não for passado aqui ou no escopo, o AD FS usará uma urna de recurso padrão:microsoft:userinfo. As políticas de recursos userinfo, como MFA, emissão ou política de autorização, não podem ser personalizadas.
modo_de_resposta opcional Especifica o método que deve ser usado para enviar o token resultante de volta para seu aplicativo. O padrão é fragment.
Estado opcional Um valor incluído na solicitação que também deve ser retornado na resposta do token. Pode ser uma sequência de qualquer conteúdo que desejar. Um valor exclusivo gerado aleatoriamente é normalmente usado para evitar ataques de falsificação de solicitação entre sites. O estado também é usado para codificar informações sobre o estado do usuário no aplicativo antes da solicitação de autenticação ocorrer, como a página ou a exibição em que eles estavam.
Sugestão opcional Indica o tipo de interação do usuário necessária. Os únicos valores válidos neste momento são login e nenhum.
- prompt=login força o usuário a inserir suas credenciais nessa solicitação, negando o logon único.
-  prompt=none é o oposto - garante que o usuário não seja apresentado com qualquer prompt interativo. Se a solicitação não puder ser realizada de forma discreta por meio do logon único, o AD FS retornará um erro de interaction_required.
login_hint opcional Pode ser usado para pré-preencher o campo de nome de usuário/endereço de e-mail da página de login do usuário, se você souber seu nome de usuário com antecedência. Muitas vezes, os aplicativos usam esse parâmetro durante a reautenticação, já tendo extraído o nome de usuário de um login anterior usando a upn declaração de id_token.
sugestão_de_domínio opcional Se incluído, ele ignora o processo de descoberta baseado em domínio pelo qual o usuário passa na página de entrada, levando a uma experiência de usuário um pouco mais simplificada.

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

Resposta com êxito

Uma resposta bem-sucedida usando response_mode=fragment and response_type=id_token+token tem o seguinte aspeto:

// 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
Parâmetro Descrição
token de acesso Incluído se response_type inclui token.
tipo_de_token Incluído se response_type inclui token. é sempre "Portador".
expira em Incluído se response_type inclui token. Indica o número de segundos em que o token é válido, para fins de cache.
Âmbito de aplicação Indica o(s) âmbito(s) para o(s) qual(is) a access_token é válida.
id_token (token de identificação) Incluído se response_type inclui id_token. Um JSON Web Token (JWT) assinado. O aplicativo pode decodificar os segmentos desse token para solicitar informações sobre o usuário que fez login. O aplicativo pode armazenar os valores em cache e exibi-los, mas não deve depender deles para quaisquer limites de autorização ou segurança.
Estado Se um parâmetro de estado for incluído na solicitação, o mesmo valor deverá aparecer na resposta. O aplicativo deve verificar se os valores de estado na solicitação e na resposta são idênticos.

Atualizar tokens

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

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

Observação

A Microsoft recomenda vivamente migrar para o Microsoft Entra ID em vez de atualizar para uma versão mais recente do AD FS. Para obter mais informações sobre o fluxo de concessão de código de autorização no Microsoft Entra ID, consulte Fluxo de concessão de código de autorização na plataforma de identidade da Microsoft.

A concessão de código de autorização OAuth 2.0 pode ser usada 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:

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

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
Parâmetro Obrigatório/Opcional Descrição
ID do cliente obrigatório A ID do Aplicativo (cliente) que o AD FS atribuiu ao seu aplicativo.
tipo_de_resposta obrigatório Deve incluir código para o fluxo de código de autorização.
uri_de_redirecionamento obrigatório O redirect_uri da sua aplicação, onde as respostas de autenticação podem ser enviadas e recebidas pela sua aplicação. Ele deve corresponder exatamente a um dos redirect_uris que você registrou no AD FS para o cliente.
recurso opcional A url da sua API Web.
Observação – Se estiver usando 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 e.g., openid]
Se o recurso não for passado aqui ou no escopo, o AD FS usará uma urna de recurso padrão:microsoft:userinfo. As políticas de recursos userinfo, como MFA, emissão ou política de autorização, não podem ser personalizadas.
Âmbito de aplicação opcional Uma lista de escopos separados por espaço.
modo_de_resposta opcional Especifica o método que deve ser usado para enviar o token resultante de volta para seu aplicativo. Pode ser um dos seguintes métodos:
- query
- fragment
- form_post
query fornece o código como um parâmetro de cadeia de caracteres de consulta no URI de redirecionamento. Se você estiver solicitando o código, poderá usar consulta, fragmento ou form_post.  form_post executa um POST que contém o código para o URI de redirecionamento.
Estado opcional Um valor incluído na solicitação que também deve ser retornado na resposta do token. Pode ser uma sequência de qualquer conteúdo que desejar. Um valor exclusivo gerado aleatoriamente é normalmente usado para evitar ataques de falsificação de solicitação entre sites. O valor também pode codificar informações sobre o estado do usuário no aplicativo antes da solicitação de autenticação ocorrer, como a página ou a exibição em que eles estavam.
Sugestão opcional Indica o tipo de interação do usuário necessária. Os únicos valores válidos neste momento são login e nenhum.
- prompt=login força o usuário a inserir suas credenciais nessa solicitação, negando o logon único.
-  prompt=none é o oposto - garante que o usuário não seja apresentado com qualquer prompt interativo. Se a solicitação não puder ser realizada de forma discreta por meio do logon único, o AD FS retornará um erro de interaction_required.
login_hint opcional Pode ser usado para pré-preencher o campo de nome de usuário/endereço de e-mail da página de login do usuário, se você souber seu nome de usuário com antecedência. Muitas vezes, os aplicativos usam esse parâmetro durante a reautenticação, já tendo extraído o nome de usuário de um login anterior usando a upndeclaração de id_token.
sugestão_de_domínio opcional Se incluído, ele ignora o processo de descoberta baseado em domínio pelo qual o usuário passa na página de entrada, levando a uma experiência de usuário um pouco mais simplificada.
método_desafio_código opcional O método usado para codificar o code_verifier para o parâmetro code_challenge. Pode ser um dos seguintes valores:
- simples
- S256
Se excluído, code_challenge é considerado texto sem formatação se code_challenge for incluído. O AD FS suporta tanto o algoritmo de texto simples quanto o S256. Para obter mais informações, consulte a RFC PKCE.
desafio_de_código opcional Usado para assegurar concessões de código de autorização por meio de Proof Key for Code Exchange (PKCE) a partir de um cliente nativo. Obrigatório se code_challenge_method estiver incluído. Para obter mais informações, consulte o PKCE RFC

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

Resposta com êxito

Uma resposta bem-sucedida usando response_mode=query tem a seguinte aparência:

GET https://adfs.contoso.com/common/oauth2/nativeclient?
code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&state=12345
Parâmetro Descrição
código O authorization_code que a aplicação solicitou. O aplicativo pode usar o código de autorização para solicitar um token de acesso para o recurso de destino. Authorization_codes são de curta duração, normalmente expiram após cerca de 10 minutos.
Estado Se um state parâmetro for incluído na solicitação, o mesmo valor deverá aparecer na resposta. O aplicativo deve verificar se os valores de estado na solicitação e na resposta são idênticos.

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)
Parâmetro Obrigatório/opcional Descrição
ID do cliente obrigatório A ID do Aplicativo (cliente) que o AD FS atribuiu ao seu aplicativo.
grant_type obrigatório Deve ser authorization_code para o fluxo de código de autorização.
código obrigatório O authorization_code que adquiriste na primeira fase do fluxo.
uri_de_redirecionamento obrigatório O valor redirect_uri que foi utilizado para adquirir o authorization_code é o mesmo.
segredo_do_cliente Necessário para aplicativos Web O segredo do aplicativo que você criou durante o registro do aplicativo no AD FS. Você não deve usar o segredo do aplicativo em um aplicativo nativo porque client_secrets não pode ser armazenado de forma confiável nos dispositivos. É necessário para aplicações Web e APIs Web, que têm a capacidade de armazenar os client_secret de forma segura no lado do servidor. O segredo do cliente deve ser codificado por URL antes de ser enviado. Esses aplicativos também podem usar uma autenticação baseada em chave ao assinar um JWT e adicioná-lo como parâmetro client_assertion.
verificador_de_código opcional O mesmo code_verifier que foi usado para obter o authorization_code. Necessário se PKCE foi usado na solicitação de concessão de código de autorização. Para obter mais informações, consulte a RFC PKCE. Esta opção aplica-se ao AD FS 2019 e versões posteriores

Resposta com êxito

Uma resposta de token bem-sucedida é semelhante a:

{
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
    "token_type": "Bearer",
    "expires_in": 3599,
    "refresh_token": "AwABAAAAvPM1KaPlrEqdFSBzjqfTGAMxZGUTdM0t4B4...",
    "refresh_token_expires_in": 28800,
    "id_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJub25lIn0.eyJhdWQiOiIyZDRkMTFhMi1mODE0LTQ2YTctOD...",
}
Parâmetro Descrição
token de acesso O token de acesso solicitado. O aplicativo pode usar esse token para autenticar no recurso seguro (API Web).
tipo_de_token Indica o valor do tipo de token. O único tipo suportado pelo AD FS é Bearer.
expira em Por quanto tempo o token de acesso é válido (em segundos).
token de atualização Um token de atualização OAuth 2.0. O aplicativo pode usar esse token para adquirir mais tokens de acesso depois que o token de acesso atual expirar. Refresh_tokens são de longa duração e podem ser usados para manter o acesso aos recursos por longos períodos de tempo.
refresh_token_expira_em Por quanto tempo o token de atualização é válido (em segundos).
id_token (token de identificação) Um token Web JSON (JWT). O aplicativo pode decodificar os segmentos desse token para solicitar informações sobre o usuário que fez login. O aplicativo pode armazenar os valores em cache e exibi-los, mas não deve depender deles para quaisquer limites de autorização ou segurança.

Usar o token de acesso

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

Atualizar 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 o token 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. De acordo com 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 o token 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, visite 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)
Parâmetro Obrigatório/Opcional Descrição
ID do cliente obrigatório A ID do Aplicativo (cliente) que o AD FS atribuiu ao seu aplicativo.
grant_type obrigatório Deve ser refresh_token para esta etapa do fluxo do código de autorização.
recurso opcional A url da sua API Web.
Observação – Se estiver usando 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 e.g., openid]
Se o recurso não for passado aqui ou no escopo, o AD FS usará uma urna de recurso padrão:microsoft:userinfo. As políticas de recursos userinfo, como MFA, emissão ou política de autorização, não podem ser personalizadas.
Âmbito de aplicação opcional Uma lista de escopos separados por espaço.
token de atualização obrigatório O refresh_token que foi adquirido na segunda etapa do fluxo.
segredo_do_cliente Necessário para aplicativos Web O segredo da aplicação que criaste no portal de registo da aplicação para a tua aplicação. Ele não deve ser usado em um aplicativo nativo, porque client_secrets não pode ser armazenado de forma confiável em dispositivos. É necessário para aplicações Web e APIs Web, que têm a capacidade de armazenar os client_secret de forma segura no lado do servidor. Esses aplicativos também podem usar uma autenticação baseada em chave ao assinar um JWT e adicioná-lo como parâmetro client_assertion.

Resposta com êxito

Uma resposta de token bem-sucedida se parece com:

{
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
    "token_type": "Bearer",
    "expires_in": 3599,
    "refresh_token": "AwABAAAAvPM1KaPlrEqdFSBzjqfTGAMxZGUTdM0t4B4...",
    "refresh_token_expires_in": 28800,
    "id_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJub25lIn0.eyJhdWQiOiIyZDRkMTFhMi1mODE0LTQ2YTctOD...",
}
Parâmetro Descrição
token de acesso O token de acesso solicitado. O aplicativo pode usar esse token para autenticar o recurso seguro, como uma API da Web.
tipo_de_token Indica o valor do tipo de token. O único tipo que o AD FS suporta é Bearer
expira em Por quanto tempo o token de acesso é válido (em segundos).
Âmbito de aplicação Os escopos para os quais o access_token é válido.
token de atualização Um token de atualização OAuth 2.0. O aplicativo pode usar esse token para adquirir mais tokens de acesso depois que o token de acesso atual expirar. Refresh_tokens são de longa duração e podem ser usados para manter o acesso aos recursos por longos períodos de tempo.
refresh_token_expira_em Por quanto tempo o token de atualização é válido (em segundos).
id_token (token de identificação) Um JSON Web Token (JWT). O aplicativo pode decodificar os segmentos desse token para solicitar informações sobre o usuário que fez login. O aplicativo pode armazenar os valores em cache e exibi-los, mas não deve depender deles para quaisquer limites de autorização ou segurança.

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 agora 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 do OAuth 2.0. O diagrama a seguir mostra um esquema visual do processo PKCE quando um cliente contacta o AD FS no Windows Server 2019.

Diagrama da relação PKCE entre o cliente e o AD FS 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. O cliente, em seguida, 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 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). Essas políticas Você pode defini-las para um RP específico ou em 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, agora você pode usar regras de declarações para decidir qual outro provedor de autenticação invocar para autenticação extra. Esse recurso é útil para dois cenários:

  • Os usuários estão fazendo a transição de um outro 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ê gerencia usar o Azure AD MFA e um grupo para usar certificados como um provedor de autenticação extra.

Se quiser controlar quantas pessoas se registram para autenticação de certificado e MFA do Azure AD, execute 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 o Azure AD Multi-Factor Authentication 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 o Certificado 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étodos 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 que usar para a http://schemas.microsoft.com/claims/authnmethodsproviders declaração deve ser um dos nomes de provedores fornecidos pela lista de provedores retornada 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 ligado emBehalf-Of

Observação

A Microsoft recomenda vivamente migrar para o Microsoft Entra ID em vez de atualizar para uma versão mais recente do AD FS. Para obter mais informações sobre o fluxo On-Behalf-Of no Microsoft Entra ID, consulte o fluxo On-Behalf-Of na plataforma de identidade da Microsoft.

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 o usuário tenha sido 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 solicite o escopo de 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.

Fluxo em nome de

  1. A aplicação cliente faz uma solicitação à API A com o token A. Nota: Ao configurar o fluxo OBO no AD FS, certifique-se de que o escopo user_impersonation está selecionado e que o cliente solicita o escopo user_impersonation 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 aceder à API B. Nota: Ao configurar este fluxo no AD FS, certifique-se de que a API A também está registada como uma aplicação de servidor com clientID com o mesmo valor que o 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 seguintes parâmetros.

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:

Parâmetro Obrigatório/Opcional Descrição
tipo_de_concessão obrigatório O tipo de solicitação de token. Para uma solicitação usando um JWT, o valor deve ser urn:ietf:params:oauth:grant-type:jwt-bearer.
ID do cliente obrigatório A ID do Cliente que você configura ao registrar sua primeira API Web como um aplicativo de servidor (aplicativo de camada intermediária). Deve ser o mesmo que o ID do recurso usado na primeira etapa, ou seja, url da primeira API Web.
segredo_do_cliente obrigatório O segredo do aplicativo que você criou durante o registro do aplicativo de servidor no AD FS.
afirmação obrigatório O valor do token usado na solicitação.
uso_de_token_solicitado obrigatório Especifica como a solicitação deve ser processada. No fluxo OBO, o valor deve ser definido como on_behalf_of
recurso obrigatório O ID do recurso fornecido durante o registro da primeira API Web como o aplicativo de servidor (aplicativo de camada intermediária). O ID do recurso deve ser o URL da aplicação de camada intermediária da segunda Web API, que faz chamadas em nome do cliente.
Âmbito de aplicação opcional Uma lista de escopos separada por espaços para a solicitação de token.

Exemplo

As solicitações a seguir HTTP POST solicitam 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:

Parâmetro obrigatório/opcional Descrição
tipo_de_concessão obrigatório O tipo de solicitação de token. Para uma solicitação usando um JWT, o valor deve ser urn:ietf:params:oauth:grant-type:jwt-bearer.
ID do cliente obrigatório A ID do Cliente que você configura ao registrar sua primeira API Web como um aplicativo de servidor (aplicativo de camada intermediária). Deve ser o mesmo que o ID do recurso usado na primeira etapa, ou seja, url da primeira API Web.
client_assertion_type obrigatório O valor deve ser urn:ietf:params:oauth:client-assertion-type:jwt-bearer.
declaração_do_cliente obrigatório Uma asserção (um token da web JSON) que precisas criar e assinar com o certificado que registaste como as credenciais para a tua aplicação.
afirmação obrigatório O valor do token usado na solicitação.
uso_de_token_solicitado obrigatório Especifica como a solicitação deve ser processada. No fluxo OBO, o valor deve ser configurado como on_behalf_of
recurso obrigatório O ID do recurso fornecido durante o registro da primeira API Web como o aplicativo de servidor (aplicativo de camada intermediária). O ID do recurso deve ser o URL da aplicação de camada intermediária da segunda Web API, que faz chamadas em nome do cliente.
Âmbito de aplicação opcional Uma lista de escopos separados por espaço para a solicitação de token.

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.

Exemplo

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 de serviço para serviço

Uma resposta de sucesso é uma resposta JSON OAuth 2.0 com os seguintes parâmetros.

Parâmetro Descrição
tipo_de_token Indica o valor do tipo de token. O único tipo suportado pelo AD FS é Bearer.
Âmbito de aplicação O escopo do acesso concedido no token.
expira em O período de tempo, em segundos, em que o token de acesso é válido.
token de acesso O token de acesso solicitado. O serviço de chamada pode usar esse token para autenticar o serviço de recebimento.
id_token (token de identificação) Um token Web JSON (JWT). O aplicativo pode decodificar os segmentos desse token para solicitar informações sobre o usuário que fez login. O aplicativo pode armazenar os valores em cache e exibi-los, mas não deve depender deles para quaisquer limites de autorização ou segurança.
token de atualização O token de atualização para o token de acesso solicitado. O serviço de chamada pode usar esse token para solicitar outro token de acesso depois que o token de acesso atual expirar.
Tempo_de_expiração_do_token_de_atualização A duração, em segundos, do tempo em que o token de atualização é válido.

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,
}

Usar 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, definindo o token no cabeçalho Authorization.

Exemplo

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

Fluxo de concessão de credenciais do cliente

Observação

A Microsoft recomenda vivamente migrar para o Microsoft Entra ID em vez de atualizar para uma versão mais recente do AD FS. Para obter mais informações sobre o fluxo de concessão de credenciais do cliente no Microsoft Entra ID, consulte Fluxo de concessão de credenciais do cliente na plataforma de identidade da Microsoft.

Você pode usar a concessão de credenciais de cliente OAuth 2.0 especificada na 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.

Credenciais do cliente

Solicite um token

Para obter um token usando a concessão de autorização de credenciais de cliente, envie uma POST solicitação para o endpoint /token do AD FS.

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

POST /adfs/oauth2/token HTTP/1.1
//Line breaks for clarity

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
Parâmetro Obrigatório/Opcional Descrição
ID do cliente obrigatório A ID do Aplicativo (cliente) que o AD FS atribuiu ao seu aplicativo.
Âmbito de aplicação opcional Uma lista separada por espaços de escopos para os quais você deseja que o usuário consinta.
segredo_do_cliente obrigatório O segredo do cliente que você gerou para seu aplicativo no portal de registro do aplicativo. O segredo do cliente deve ser codificado por URL antes de ser enviado.
grant_type obrigatório Deve ser definido como client_credentials.

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

POST /adfs/oauth2/token HTTP/1.1

// Line breaks for clarity

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
Parâmetro Obrigatório/Opcional Descrição
client_assertion_type obrigatório O valor deve ser definido como urn:ietf:params:oauth:client-assertion-type:jwt-bearer.
declaração_do_cliente obrigatório Uma asserção (um token da web JSON) que precisas criar e assinar com o certificado que registaste como as credenciais para a tua aplicação.
tipo_de_concessão obrigatório Deve ser definido como client_credentials.
ID do cliente opcional A ID do Aplicativo (cliente) que o AD FS atribuiu ao seu aplicativo. Faz parte de client_assertion, por isso não é obrigatório passar neste contexto.
Âmbito de aplicação opcional Uma lista separada por espaços de escopos para os quais você deseja que o usuário consinta.

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

Observação

A Microsoft recomenda vivamente migrar para o Microsoft Entra ID em vez de atualizar para uma versão mais recente do AD FS. Para obter mais informações sobre o fluxo de concessão de credenciais de senha do proprietário do recurso no ID do Microsoft Entra, consulte Fluxo de concessão de credenciais de senha do proprietário do recurso na plataforma de identidade da Microsoft.

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 e você só deve usar esse fluxo quando outros fluxos mais seguros não puderem ser usados.

Diagrama de protocolo

O diagrama a seguir mostra o fluxo ROPC.

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
Parâmetro Obrigatório/Opcional Descrição
ID do cliente obrigatório ID do Cliente
tipo_de_concessão obrigatório Deve ser definido como palavra-passe.
nome de utilizador obrigatório O endereço de e-mail do usuário.
palavra-passe obrigatório A senha do usuário.
Âmbito de aplicação opcional Uma lista de escopos separados por espaço.

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..."
}
Parâmetro Descrição
tipo_de_token Sempre definido como Portador.
Âmbito de aplicação Se um token de acesso foi retornado, esse parâmetro lista os escopos para os quais o token de acesso é válido.
expira em Número de segundos para os quais o token de acesso incluído é válido.
token de acesso Emitido para os escopos que foram solicitados.
id_token (token de identificação) Um token Web JSON (JWT). O aplicativo pode decodificar os segmentos desse token para solicitar informações sobre o usuário que fez login. O aplicativo pode armazenar os valores em cache e exibi-los, mas não deve depender deles para quaisquer limites de autorização ou segurança.
refresh_token_expira_em Número de segundos para os quais o token de atualização incluído é válido.
token de atualização Emitido se o parâmetro de escopo original incluísse offline_access.

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 fluxo de concessão de código de autenticação deste artigo.

Fluxo de código do dispositivo

Observação

A Microsoft recomenda vivamente migrar para o Microsoft Entra ID em vez de atualizar para uma versão mais recente do AD FS. Para obter mais informações sobre o fluxo de código de dispositivo no Microsoft Entra ID, consulte Fluxo de código de dispositivo na plataforma de identidade da Microsoft.

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 diagrama seguinte. Descrevemos cada uma das etapas mais adiante neste artigo.

Fluxo de código do dispositivo

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 este pedido é enviado, o utilizador tem apenas 15 minutos para iniciar sessão (o valor habitual para expires_in), pelo que só faz este pedido quando o utilizador tiver indicado que está pronto para iniciar sessão.

// 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
Parâmetro Condição Descrição
ID do cliente obrigatório A ID do Aplicativo (cliente) que o AD FS atribuiu ao seu aplicativo.
Âmbito de aplicação opcional Uma lista de escopos separados por espaço.

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.

Parâmetro Descrição
código_do_dispositivo Uma cadeia de caracteres longa usada para verificar a sessão entre o cliente e o servidor de autorização. O cliente usa esse parâmetro para solicitar o token de acesso do servidor de autorização.
código_do_utilizador Uma cadeia de caracteres curta mostrada ao usuário que é usada para identificar a sessão em um dispositivo secundário.
URI de verificação O URI ao qual o usuário deve ir com o user_code para entrar.
uri_de_verificação_completa O URI ao qual o usuário deve ir com o user_code para entrar. Está pré-preenchido com user_code para que o utilizador não precise de introduzir user_code.
expira em O número de segundos antes dos códigos device_code e user_code expirarem.
intervalo O número de segundos que o cliente deve aguardar entre as solicitações de sondagem.
Mensagem Uma string legível por humanos com instruções para o usuário. Pode-se localizá-lo incluindo um parâmetro de consulta no formato de pedido ?mkt=xx-XX e preenchendo o código de cultura de idioma apropriado.

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
Parâmetro obrigatório Descrição
grant_type obrigatório Deve ser urn:ietf:params:oauth:grant-type:device_code
ID do cliente obrigatório Deve corresponder ao client_id usado na solicitação inicial.
código obrigatório O código_do_dispositivo retornado na solicitação de autorização do dispositivo.

Resposta de autenticação bem-sucedida

Uma resposta de token bem-sucedida se parece com:

Parâmetro Descrição
tipo_de_token Sempre "portador".
Âmbito de aplicação Se um token de acesso foi retornado, ele lista os escopos para os quais o token de acesso é válido.
expira em Número de segundos até que o token de acesso incluído se torne válido.
token de acesso Emitido para os escopos que foram solicitados.
id_token (token de identificação) Emitido se o parâmetro de escopo original incluísse o escopo openid.
token de atualização Emitido se o parâmetro de escopo original incluísse offline_access.
refresh_token_expira_em Número de segundos antes que o token de atualização incluído seja válido.

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.