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

Aplica-se ao AD FS 2019 e posterior

Cenário	Apresentação passo a passo do cenário usando amostras	Fluxo/Concessão do OAuth 2.0	Tipo de Cliente
Aplicativo de página única	Amostra usando MSAL	Implícito	Público
Aplicativo Web que conecta os usuários	Amostra usando OWIN	Código de Autorização	Público, Confidencial
O aplicativo nativo chama a API Web	Amostra usando MSAL	Código de Autorização	Público
O aplicativo Web chama a API Web	Amostra usando MSAL	Código de Autorização	Confidencial
Implementação PKCE		Código de Autorização	Setor Público
A API Web chama outra API Web OBO (on behalf of ou em nome do) usuário	Amostra usando MSAL	On-behalf-of	O aplicativo Web atua como Confidencial
O aplicativo daemon chama a API Web		Credenciais de cliente	Confidencial
O aplicativo Web chama a API Web usando credenciais do usuário		Credenciais de senha de proprietário do recurso	Público, Confidencial
O aplicativo sem navegador chama a API Web		Código do dispositivo	Público, Confidencial

Fluxo de concessão implícita

Para aplicativos de página única (AngularJS, Ember.js, reajam.js e assim por diante), o AD FS é compatível com o fluxo de concessão implícita do OAuth 2.0. O fluxo está descrito na Especificação do 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. É preciso considerar algumas questões de segurança importantes ao usar o fluxo implícito especificamente em relação ao 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 do 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 em mais detalhes.

Solicitar token de ID e token de acesso

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

Parâmetro	Obrigatório/Opcional	Descrição
client_id	necessárias	A ID do aplicativo (cliente) que o AD FS atribuiu ao seu aplicativo.
response_type	necessárias	Deve incluir id_token para conexão do OpenID Connect. Também pode incluir o response_type token. O uso de token aqui permite que o aplicativo receba um token de acesso imediatamente do ponto de extremidade de autorização sem precisar fazer uma segunda solicitação ao ponto de extremidade do token.
redirect_uri	necessárias	O redirect_uri de seu aplicativo, em que as respostas de autenticação podem ser enviadas e recebidas pelo seu aplicativo. Ele deve corresponder exatamente a um dos redirect_uris configurados no AD FS.
nonce	necessárias	Um valor incluído na solicitação, gerado pelo aplicativo, deve ser incluído no id_token resultante como uma declaração. O aplicativo pode, então, verificar esse valor para atenuar os ataques de reproduçã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. Obrigatório somente quando um id_token é solicitado.
escopo	opcionais	Uma lista de escopos separados por espaços. Para o OpenID Connect, deve incluir o escopo openid.
recurso	opcionais	O URL da API Web. Observação – caso esteja usando a biblioteca de cliente do MSAL, o parâmetro de recurso não será enviado. Em vez disso, a URL do recurso é enviada como parte do parâmetro de escopo: scope = [resource url]//[scope values e.g., openid] se o recurso não for passado aqui ou no escopo, o AD FS usa um recurso padrão urn:microsoft:userinfo. As políticas de recurso userinfo, como MFA, Emissão ou política de emissão, não podem ser personalizadas.
response_mode	opcionais	Especifica o método que deve ser usado para enviar o token resultante de volta ao seu aplicativo. O padrão é fragment.
state	opcionais	Um valor incluído na solicitação que também deve ser retornado na resposta do token. Pode ser uma cadeia de caracteres de qualquer conteúdo desejado. Um valor exclusivo gerado aleatoriamente que normalmente é usado para impedir ataques de solicitação intersite forjada. O estado também é usado para codificar informações sobre o estado do usuário no aplicativo antes que a solicitação de autenticação ocorra, como a página ou a exibição em que ele estava.
prompt	opcionais	Indica o tipo de interação do usuário que é necessário. Os únicos valores válidos neste momento são entrada e nenhum. - prompt=login força o usuário a inserir as credenciais nessa solicitação, negando o logon único. - prompt=noneé o oposto – ele garante que não seja apresentado nenhum prompt interativo ao usuário. Se a solicitação não puder ser concluída silenciosamente por meio de logon único, o AD FS retorna um erro de interaction_required.
login_hint	opcionais	Pode ser usado para preencher previamente o campo de nome de usuário/endereço de email da página de entrada do usuário, caso você saiba o nome de usuário com antecedência. Geralmente, os aplicativos usam esse parâmetro durante a reautenticação, após já terem extraído o nome de usuário de uma entrada anterior usando a upndeclaração de id_token.
domain_hint	opcionais	Se for incluído, ele ignora o processo de descoberta baseado em domínio que o usuário passa na página de entrada, levando a uma experiência de usuário um pouco mais simplificada.

Nesse ponto, é solicitado que o usuário insira suas credenciais e conclua a autenticação. Depois que o usuário for autenticado, 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 usando response_mode=fragment and response_type=id_token+token é semelhante ao seguinte

// 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
access_token	Incluído se response_type incluir token.
token_type	Incluído se response_type incluir token. é sempre "Portador".
expires_in	Incluído se response_type incluir token. Indica o número de segundos pelos quais o token é válido para fins de cache.
escopo	Indica os escopos para os quais o access_token é válido.
id_token	Incluído se response_type incluir id_token. Um JWT (JSON Web Token) assinado. O aplicativo pode decodificar os segmentos desse token para solicitar informações sobre o usuário que se conectou. O aplicativo pode armazenar em cache os valores e exibi-los, mas não deve confiar neles para nenhuma autorização ou limite de segurança.
state	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 da solicitação e da resposta são idênticos.

Tokens de atualização

A concessão implícita não fornece tokens de atualização. id_tokens e access_tokens vão expirar após um curto período, de modo que seu aplicativo deve estar preparado para atualizar esses tokens periodicamente. Para atualizar qualquer tipo de token, você pode executar a mesma solicitação de iframe oculto na seção anterior usando o parâmetro prompt=none para controlar o comportamento da plataforma de identidade. Se você quiser receber new id_token, use response_type=id_token.

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

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

Parâmetro	Obrigatório/Opcional	Descrição
client_id	necessárias	A ID do aplicativo (cliente) que o AD FS atribuiu ao seu aplicativo.
response_type	obrigatório	Deve incluir código para o fluxo do código de autorização.
redirect_uri	necessárias	O redirect_uri de seu aplicativo, em que as respostas de autenticação podem ser enviadas e recebidas pelo seu aplicativo. Deve corresponder exatamente a um dos redirect_uris que você registrou no AD FS para o cliente.
recurso	opcionais	O URL da API Web. Observação – caso esteja usando a biblioteca de cliente do MSAL, o parâmetro de recurso não será enviado. Em vez disso, a URL do recurso é enviada como parte do parâmetro de escopo: scope = [resource url]//[scope values e.g., openid] se o recurso não for passado aqui ou no escopo, o AD FS usa um recurso padrão urn:microsoft:userinfo. As políticas de recurso userinfo, como MFA, Emissão ou política de emissão, não podem ser personalizadas.
escopo	opcionais	Uma lista de escopos separados por espaços.
response_mode	opcionais	Especifica o método que deve ser usado para enviar o token resultante de volta ao 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 query, fragment ou form_post. form_post executa um POST contendo o código para o URI de redirecionamento.
state	opcionais	Um valor incluído na solicitação que também deve ser retornado na resposta do token. Pode ser uma cadeia de caracteres de qualquer conteúdo desejado. Um valor exclusivo gerado aleatoriamente que normalmente é usado para impedir ataques de solicitação intersite forjada. O valor também pode codificar informações sobre o estado do usuário no aplicativo antes que a solicitação de autenticação ocorra, como a página ou a exibição em que ele estava.
prompt	opcionais	Indica o tipo de interação do usuário que é necessário. Os únicos valores válidos neste momento são entrada e nenhum. - prompt=login força o usuário a inserir as credenciais nessa solicitação, negando o logon único. - prompt=noneé o oposto – ele garante que não seja apresentado nenhum prompt interativo ao usuário. Se a solicitação não puder ser concluída silenciosamente por meio de logon único, o AD FS retorna um erro de interaction_required.
login_hint	opcionais	Pode ser usado para preencher previamente o campo de nome de usuário/endereço de email da página de entrada do usuário, caso você saiba o nome de usuário com antecedência. Geralmente, os aplicativos usam esse parâmetro durante a reautenticação, após já terem extraído o nome de usuário de uma entrada anterior usando a upn declaração de id_token.
domain_hint	opcionais	Se for incluído, ele ignora o processo de descoberta baseado em domínio que o usuário passa na página de entrada, levando a uma experiência de usuário um pouco mais simplificada.
code_challenge_method	opcionais	O método usado para codificar o code_verifier para o parâmetro code_challenge. Pode ser um dos seguintes valores: - plain - S256 Se excluído, code_challenge será considerado texto sem formatação se code_challenge estiver incluído. O AD FS é compatível com plain e S256. Para mais informações, consulte PKCE RFC.
code_challenge	opcionais	Usado para proteger as concessões de código de autorização por meio da PKCE (Chave de Prova para Troca de Código) de um cliente nativo. Necessário se code_challenge_method estiver incluído. Para obter mais informações, consulte PKCE RFC

Nesse ponto, é solicitado que o usuário insira suas credenciais e conclua a autenticação. Depois que o usuário for autenticado, o 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 usando response_mode=query é semelhante a:

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

Parâmetro	Descrição
code	O authorization_code que o aplicativo solicitou. O aplicativo pode usar o código de autorização para solicitar um token de acesso ao recurso alvo. Authorization_codes têm vida curta, normalmente expiram após cerca de 10 minutos.
state	Se um parâmetro state for incluído na solicitação, o mesmo valor deverá aparecer na resposta. O aplicativo deve verificar se os valores de estado da solicitação e da resposta são idênticos.

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)

Parâmetro	Obrigatório/opcional	Descrição
client_id	necessárias	A ID do aplicativo (cliente) que o AD FS atribuiu ao seu aplicativo.
grant_type	obrigatório	Deve ser authorization_code para o fluxo do código de autorização.
code	necessárias	O authorization_code que você adquiriu no primeiro segmento do fluxo.
redirect_uri	necessárias	O mesmo valor de redirect_uri que foi usado para adquirir o authorization_code.
client_secret	obrigató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 maneira confiável em dispositivos. É obrigatório para aplicativos Web e APIs Web, que têm a capacidade de armazenar o client_secret com segurança no lado do servidor. O segredo do cliente deve ser codificado por URL antes do envio. Esses aplicativos também podem usar uma autenticação baseada em chave assinando um JWT e adicionando-o como o parâmetro client_assertion.
code_verifier	opcionais	O mesmo code_verifier usado para obter o authorization_code. Obrigatório se o PKCE foi usado na solicitação de concessão de código de autorização. Para mais informações, consulte PKCE RFC. Esta opção se aplica ao AD FS 2019 e posterior

Resposta bem-sucedida

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

{
    "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
access_token	O token de acesso solicitado. O aplicativo pode usar esse token para autenticar-se no recurso protegido (API Web).
token_type	Indica o valor do tipo de token. O único tipo com o qual AD FS é compatível é Portador.
expires_in	Por quanto tempo o token de acesso é válido (em segundos).
refresh_token	Um token de atualização do 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 têm longa duração e podem ser usados para manter o acesso aos recursos por longos períodos.
refresh_token_expires_in	Por quanto tempo o token de atualização é válido (em segundos).
id_token	Um JWT (JSON Web Token). O aplicativo pode decodificar os segmentos desse token para solicitar informações sobre o usuário que se conectou. O aplicativo pode armazenar em cache os valores e exibi-los, mas não deve confiar neles para nenhuma autorização ou limite de segurança.

Usar o token de acesso

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

Atualizar fluxo de concessão do 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 o token 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. De acordo com a especificação do OAuth 2.0: "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 o token de atualização quando a duração do novo token de atualização é maior do que a duração do token de atualização anterior. Para exibir informações adicionais sobre tempos de vida de 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
client_id	necessárias	A ID do aplicativo (cliente) que o AD FS atribuiu ao seu aplicativo.
grant_type	obrigatório	Deve ser refresh_token para essa ramificação do código de autorização.
recurso	opcionais	O URL da API Web. Observação – caso esteja usando a biblioteca de cliente do MSAL, o parâmetro de recurso não será enviado. Em vez disso, a URL do recurso é enviada como parte do parâmetro de escopo: scope = [resource url]//[scope values e.g., openid] se o recurso não for passado aqui ou no escopo, o AD FS usa um recurso padrão urn:microsoft:userinfo. As políticas de recurso userinfo, como MFA, Emissão ou política de emissão, não podem ser personalizadas.
escopo	opcionais	Uma lista de escopos separados por espaços.
refresh_token	necessárias	O refresh_token que você adquiriu no segundo segmento do fluxo.
client_secret	obrigatório para aplicativos Web	O segredo do aplicativo que você criou no portal de registro do aplicativo. Ele não deve ser usado em um aplicativo nativo, pois não é possível armazenar client_secrets de modo confiável em dispositivos. É obrigatório para aplicativos Web e APIs Web, que têm a capacidade de armazenar o client_secret com segurança no lado do servidor. Esses aplicativos também podem usar uma autenticação baseada em chave assinando um JWT e adicionando-o como o parâmetro client_assertion.

Resposta bem-sucedida

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

{
    "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
access_token	O token de acesso solicitado. O aplicativo pode usar esse token para se autenticar no recurso protegido, como uma API Web.
token_type	Indica o valor do tipo de token. O único tipo com o qual AD FS é compatível é Portador
expires_in	Por quanto tempo o token de acesso é válido (em segundos).
escopo	Os escopos para os quais o access_token é válido.
refresh_token	Um token de atualização do 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 têm longa duração e podem ser usados para manter o acesso aos recursos por longos períodos.
refresh_token_expires_in	Por quanto tempo o token de atualização é válido (em segundos).
id_token	Um JWT (JSON Web Token). O aplicativo pode decodificar os segmentos desse token para solicitar informações sobre o usuário que se conectou. O aplicativo pode armazenar em cache os valores e exibi-los, mas não deve confiar neles para nenhuma autorização ou limite de segurança.

Suporte a 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 interceptaçã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 (Chave de Prova para Troca de Código) 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 uma estrutura de tópicos visual 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 normalmente, 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 denominada 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á acesso.

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

O AD FS já oferece suporte ao acionamento de autenticação extra com base em uma diretiva de regra de declaraçã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 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, 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 diretivas 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 para usar o Azure AD MFA e um grupo para usar certificados como um provedor de autenticação extra.

Se você quiser controlar quantas pessoas se registram para o Azure AD MFA e autenticação de certificado, execute um comando como este com os valores substituídos por outros 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 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 fazer regras para permitir mais de um provedor de autenticação adicional. Nesse caso, o AD FS mostra os provedores de métodos de autenticação emitidos e o 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 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 adicionais configurados pelo administrador no AD FS. O usuário deve selecionar manualmente o provedor de autenticação apropriado.

Se seu 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 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 diretiva 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 nível intermediário faça solicitações autenticadas ao serviço downstream, ele precisa proteger um token de acesso do AD FS em nome do usuário.

Diagrama do protocolo

Suponha que o usuário tenha sido autenticado em um aplicativo usando o fluxo de concessão de código de autorização do 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). O cliente deve solicitar o escopo user_impersonation 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 para a API A com o token A. Observação: Ao configurar o fluxo OBO no AD FS, user_impersonation deve estar selecionado e o cliente deve solicitar o escopo user_impersonation na solicitação.
2. A API A é autenticada no ponto de extremidade de emissão de token do AD FS e solicita um token para acessar a API B. Observação: ao configurar esse fluxo no AD FS, verifique se a API A também está registrada como um aplicativo para servidores com clientID com o mesmo valor que a ID de 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 para o ponto de extremidade do token AD FS com os parâmetros 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:

Parâmetro	Obrigatório/Opcional	Descrição
grant_type	necessárias	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.
client_id	necessárias	A ID do cliente que você configura ao registrar sua primeira API Web como um aplicativo de servidor (aplicativo de nível intermediário). Deve ser igual à ID do recurso usada no primeiro segmento, ou seja, o URL da primeira API Web.
client_secret	obrigatório	O segredo do aplicativo que você criou durante o registro do aplicativo de servidor no AD FS.
assertion	necessárias	O valor do token usado na solicitação.
requested_token_use	necessárias	Especifica como a solicitação deve ser processada. No fluxo OBO, o valor deve ser definido como on_behalf_of
recurso	necessárias	A ID de recurso fornecida ao registrar a primeira API Web como o aplicativo de servidor (Aplicativo de nível intermediário). A ID do recurso deve ser o URL da segunda API Web que o Aplicativo de nível intermediário chama em nome do cliente.
escopo	opcionais	Uma lista de escopos separados por espaços para a solicitação de token.

Exemplo

O HTTP POST a seguir 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:

Parâmetro	obrigatório/Opcional	Descrição
grant_type	necessárias	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.
client_id	necessárias	A ID do cliente que você configura ao registrar sua primeira API Web como um aplicativo de servidor (aplicativo de nível intermediário). Deve ser igual à ID do recurso usada no primeiro segmento, ou seja, o URL da primeira API Web.
client_assertion_type	necessárias	O valor deve ser urn:ietf:params:oauth:client-assertion-type:jwt-bearer.
client_assertion	obrigatório	Uma asserção (um token Web JSON) que você precisa criar e assinar com o certificado que você registrou como credenciais para seu aplicativo.
assertion	necessárias	O valor do token usado na solicitação.
requested_token_use	necessárias	Especifica como a solicitação deve ser processada. No fluxo OBO, o valor deve ser definido como on_behalf_of
recurso	necessárias	A ID de recurso fornecida ao registrar a primeira API Web como o aplicativo de servidor (Aplicativo de nível intermediário). A ID do recurso deve ser o URL da segunda API Web que o Aplicativo de nível intermediário chama em nome do cliente.
escopo	opcionais	Uma lista de escopos separados por espaços 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 pelo fato de 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 de token de acesso de serviço a serviço

Uma resposta de êxito é uma resposta JSON OAuth 2.0 com os parâmetros a seguir.

Parâmetro	Descrição
token_type	Indica o valor do tipo de token. O único tipo com o qual AD FS é compatível é Portador.
scope	O escopo do acesso concedido no token.
expires_in	O período, em segundos, pelo qual o token de acesso é válido.
access_token	O token de acesso solicitado. O serviço de chamada pode usar esse token para se autenticar no serviço de recebimento.
id_token	Um JWT (JSON Web Token). O aplicativo pode decodificar os segmentos desse token para solicitar informações sobre o usuário que se conectou. O aplicativo pode armazenar em cache os valores e exibi-los, mas não deve confiar neles para nenhuma autorização ou limite de segurança.
refresh_token	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.
Refresh_token_expires_in	O período, em segundos, pelo qual o token de atualização é válido.

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

Use o token de acesso para acessar o recurso protegido. Agora o serviço de nível intermediário pode usar o token adquirido no exemplo de resposta anterior para fazer solicitações autenticadas para a API Web downstream, definindo o token no cabeçalho Autorização.

Exemplo

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 do cliente do OAuth 2.0 especificada em 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 de cliente do OAuth 2.0 permite que um serviço Web (cliente confidencial) use as próprias credenciais, em vez de personificação de um usuário, para autenticar-se 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 do 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 de cliente, envie uma solicitação de POST para o ponto de extremidade do AD FS /token:

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
client_id	necessárias	A ID do aplicativo (cliente) que o AD FS atribuiu ao seu aplicativo.
escopo	opcionais	Uma lista separada por espaços de escopos com os quais você deseja que o usuário consinta.
client_secret	necessárias	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 do envio.
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.
client_assertion	obrigatório	Uma asserção (um token Web JSON) que você precisa criar e assinar com o certificado que você registrou como credenciais para seu aplicativo.
grant_type	obrigatório	Deve ser definido como client_credentials.
client_id	opcionais	A ID do aplicativo (cliente) que o AD FS atribuiu ao seu aplicativo. Isso faz parte da client_assertion, portanto, não é necessário transmiti-lo aqui.
escopo	opcionais	Uma lista separada por espaços de escopos com os quais você deseja que o usuário consinta.

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

Diagrama do 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

Parâmetro	Obrigatório/Opcional	Descrição
client_id	necessárias	ID do cliente
grant_type	obrigatório	Deve ser definido como senha.
username	necessárias	O endereço de email do usuário.
password	necessárias	A senha do usuário.
escopo	opcionais	Uma lista de escopos separados por espaços.

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

Parâmetro	Descrição
token_type	Sempre definido como Portador.
escopo	Se um token de acesso for retornado, esse parâmetro listará os escopos para os quais o token de acesso é válido.
expires_in	Número de segundos pelos quais o token de acesso incluído é válido.
access_token	Emitido para os escopos solicitados.
id_token	Um JWT (JSON Web Token). O aplicativo pode decodificar os segmentos desse token para solicitar informações sobre o usuário que se conectou. O aplicativo pode armazenar em cache os valores e exibi-los, mas não deve confiar neles para nenhuma autorização ou limite de segurança.
refresh_token_expires_in	Número de segundos pelos quais o token de atualização incluído seja válido.
refresh_token	Emitido se o parâmetro de escopo original tiver incluído offline_access.

Use 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 entra, o dispositivo é capaz de obter tokens de acesso e atualizar tokens conforme necessário.

Diagrama do protocolo

Todo o fluxo de código do dispositivo é semelhante ao diagrama a seguir. Descrevemos cada uma das etapas mais adiante 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. Quando essa solicitação é enviada, o usuário tem apenas 15 minutos para entrar (o valor comum para expires_in), portanto, faça essa solicitação apenas 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

Parâmetro	Condição	Descrição
client_id	necessárias	A ID do aplicativo (cliente) que o AD FS atribuiu ao seu aplicativo.
escopo	opcionais	Uma lista de escopos separados por espaços.

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.

Parâmetro	Descrição
device_code	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.
user_code	Uma cadeia de caracteres curta mostrada para o usuário que é usada para identificar a sessão em um dispositivo secundário.
verification_uri	O URI que o usuário deve acessar com o user_code para entrar.
verification_uri_complete	O URI que o usuário deve acessar com o user_code para entrar. É pré-preenchido com user_code para que o usuário não precise inserir user_code
expires_in	O número de segundos antes da expiração de device_code e user_code.
intervalo	O número de segundos que o cliente deve aguardar entre solicitações de sondagem.
mensagem	Uma cadeia de caracteres legível por humanos com instruções para o usuário. Ele pode ser localizado com a inclusão de um parâmetro de consulta na solicitação do formulário ?mkt=xx-XX, preenchendo o código de cultura do idioma apropriado.

Como autenticar o usuário

Após o cliente receber o user_code e verification_uri, ele exibe esses detalhes para o usuário, instruindo-os a entrar usando o telefone celular ou o navegador de PC. 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 está autenticando no verification_uri, o cliente deve estar sondando o /token ponto de extremidade para 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

Parâmetro	necessárias	Descrição
grant_type	obrigatório	Deve ser urn:ietf:params:oauth:grant-type:device_code
client_id	obrigatório	Deve corresponder ao client_id usado na solicitação inicial.
code	necessárias	O device_code retornado na solicitação de autorização do dispositivo.

Resposta de autenticação bem-sucedida

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

Parâmetro	Descrição
token_type	Sempre "Portador".
scope	Se um token de acesso for retornado, ele lista os escopos para os quais o token de acesso é válido.
expires_in	Número de segundos antes que o token de acesso incluído seja válido.
access_token	Emitido para os escopos solicitados.
id_token	Emitido se o parâmetro de escopo original tiver incluído o escopo openid.
refresh_token	Emitido se o parâmetro de escopo original tiver incluído offline_access.
refresh_token_expires_in	Número de segundos antes que o token de atualização incluído seja válido.

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.