Partilhar via


Chamadas de serviço a serviço que utilizam a identidade de utilizador delegada no fluxo Em Nome de

Aviso

Este conteúdo destina-se ao ponto final Azure AD v1.0 mais antigo. Utilize o plataforma de identidades da Microsoft para novos projetos.

O fluxo OAuth 2.0 On-Behalf-Of (OBO) permite que uma aplicação que invoca um serviço ou API Web transmita a autenticação do utilizador para outro serviço ou API Web. O fluxo OBO propaga a identidade de utilizador delegado e as permissões através da cadeia de pedidos. Para que o serviço de camada média faça pedidos autenticados para o serviço a jusante, tem de proteger um token de acesso do Azure Active Directory (Azure AD) em nome do utilizador.

Importante

A partir de maio de 2018, não é possível utilizar um id_token para o fluxo Em Nome-De. As aplicações de página única (SPAs) têm de transmitir um token de acesso a um cliente confidencial de camada média para executar fluxos OBO. Para obter mais detalhes sobre os clientes que podem efetuar chamadas Em Nome de, veja limitações.

Diagrama de fluxo em nome de

O fluxo OBO é iniciado depois de o utilizador ter sido autenticado numa aplicação que utiliza o fluxo de concessão de código de autorização OAuth 2.0. Nessa altura, a aplicação envia um token de acesso (token A) para a API Web de camada média (API A) que contém as afirmações do utilizador e o consentimento para aceder à API A. Em seguida, a API A efetua um pedido autenticado para a API Web a jusante (API B).

Estes passos constituem o fluxo Em Nome de: Mostra os passos no fluxo OAuth2.0 Em Nome De

  1. A aplicação cliente faz um pedido à API A com o token A.
  2. A API A autentica-se no ponto final de emissão de tokens de Azure AD e pede um token para aceder à API B.
  3. O ponto final de emissão de tokens de Azure AD valida as credenciais da API A com o token A e emite o token de acesso para a API B (token B).
  4. O pedido à API B contém o token B no cabeçalho de autorização.
  5. A API B devolve dados do recurso protegido.

Nota

A afirmação de audiência num token de acesso utilizado para pedir um token para um serviço a jusante tem de ser o ID do serviço que faz o pedido OBO. O token também tem de ser assinado com a chave de assinatura global do Azure Active Directory (que é a predefinição para aplicações registadas através de Registos de aplicações no portal).

Registar a aplicação e o serviço no Azure AD

Registe o serviço de camada média e a aplicação cliente no Azure AD.

Registar o serviço de camada média

  1. Inicie sessão no portal do Azure.
  2. Na barra superior, selecione a sua conta e procure na lista Diretório para selecionar um inquilino do Active Directory para a sua aplicação.
  3. Selecione Mais Serviços no painel esquerdo e escolha Azure Active Directory.
  4. Selecione Registos de aplicações e, em seguida, Novo registo.
  5. Introduza um nome amigável para a aplicação e selecione o tipo de aplicação.
  6. Em Tipos de conta suportados, selecione Contas em qualquer diretório organizacional e contas Microsoft pessoais.
  7. Defina o URI de redirecionamento para o URL base.
  8. Selecione Registar para criar a aplicação.
  9. No portal do Azure, selecione a sua aplicação e selecione Certificados & segredos.
  10. Selecione Novo segredo do cliente e adicione um segredo com uma duração de um ou dois anos.
  11. Quando guarda esta página, o portal do Azure apresenta o valor do segredo. Copie e guarde o valor do segredo numa localização segura.
  12. Crie um âmbito na sua aplicação na página Expor uma API para a sua aplicação e clique em "Adicionar um âmbito". O Portal também pode exigir que crie um URI de ID de aplicação.

Importante

Precisa do segredo para configurar as definições da aplicação na sua implementação. Este valor secreto não é apresentado novamente e não é recuperável por outros meios. Grave-o assim que estiver visível no portal do Azure.

Registar a aplicação cliente

  1. Inicie sessão no portal do Azure.
  2. Na barra superior, selecione a sua conta e procure na lista Diretório para selecionar um inquilino do Active Directory para a sua aplicação.
  3. Selecione Mais Serviços no painel esquerdo e escolha Azure Active Directory.
  4. Selecione Registos de aplicações e, em seguida, Novo registo.
  5. Introduza um nome amigável para a aplicação e selecione o tipo de aplicação.
  6. Em Tipos de conta suportados, selecione Contas em qualquer diretório organizacional e contas Microsoft pessoais.
  7. Defina o URI de redirecionamento para o URL base.
  8. Selecione Registar para criar a aplicação.
  9. Configurar permissões para a sua aplicação. Nas permissões da API, selecione Adicionar uma permissão e, em seguida , As Minhas APIs.
  10. Escreva o nome do serviço de camada média no campo de texto.
  11. Selecione Selecionar Permissões e, em seguida, selecione o âmbito que criou no último passo para registar a camada média.

Configurar aplicações cliente conhecidas

Neste cenário, o serviço de camada média tem de obter o consentimento do utilizador para aceder à API a jusante sem uma interação do utilizador. A opção para conceder acesso à API a jusante tem de ser apresentada antecipadamente como parte do passo de consentimento durante a autenticação.

Siga os passos abaixo para vincular explicitamente o registo da aplicação cliente no Azure AD com o registo do serviço de camada média. Esta operação intercala o consentimento exigido pelo cliente e pela camada média numa única caixa de diálogo.

  1. Aceda ao registo de serviço de camada média e selecione Manifesto para abrir o editor de manifestos.
  2. Localize a knownClientApplications propriedade matriz e adicione o ID de cliente da aplicação cliente como um elemento.
  3. Guarde o manifesto ao selecionar Guardar.

Pedido de token de acesso serviço a serviço

Para pedir um token de acesso, crie um HTTP POST para o ponto final de Azure AD específico do inquilino com os seguintes parâmetros:

https://login.microsoftonline.com/<tenant>/oauth2/token

A aplicação cliente é protegida por um segredo partilhado ou por um certificado.

Primeiro caso: pedido de token de acesso com um segredo partilhado

Ao utilizar um segredo partilhado, um pedido de token de acesso de serviço a serviço contém os seguintes parâmetros:

Parâmetro Tipo Description
grant_type obrigatório O tipo de pedido de token. Um pedido OBO utiliza um JSON Web Token (JWT), pelo que o valor tem de ser urn:ietf:params:oauth:grant-type:jwt-bearer.
asserção obrigatório O valor do token de acesso utilizado no pedido.
client_id obrigatório O ID da aplicação atribuído ao serviço de chamadas durante o registo com Azure AD. Para localizar o ID da aplicação no portal do Azure, selecione Active Directory, selecione o diretório e, em seguida, selecione o nome da aplicação.
client_secret obrigatório A chave registada para o serviço de chamadas no Azure AD. Este valor deveria ter sido anotado no momento do registo.
recurso obrigatório O URI do ID da aplicação do serviço de receção (recurso protegido). Para localizar o URI do ID da aplicação no portal do Azure, selecione Active Directory e selecione o diretório. Selecione o nome da aplicação, selecione Todas as definições e, em seguida, selecione Propriedades.
requested_token_use obrigatório Especifica como o pedido deve ser processado. No fluxo Em Nome de, o valor tem de ser on_behalf_of.
scope obrigatório Uma lista separada por espaços de âmbitos para o pedido de token. Para o OpenID Connect, o openid do âmbito tem de ser especificado.

Exemplo

O seguinte HTTP POST pede um token de acesso para a https://graph.microsoft.com API Web. O client_id identifica o serviço que pede o token de acesso.

// line breaks for legibility only

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

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer
&client_id=625391af-c675-43e5-8e44-edd3e30ceb15
&client_secret=0Y1W%2BY3yYb3d9N8vSjvm8WrGzVZaAaHbHHcGbcgG%2BoI%3D
&resource=https%3A%2F%2Fgraph.microsoft.com
&assertion=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6InowMzl6ZHNGdWl6cEJmQlZLMVRuMjVRSFlPMCIsImtpZCI6InowMzl6ZHNGdWl6cEJmQlZLMVRuMjVRSFlPMCJ9.ewogICJhdWQiOiAiaHR0cHM6Ly9ncmFwaC5taWNyb3NvZnQuY29tIiwKICAiaXNzIjogImh0dHBzOi8vc3RzLndpbmRvd3MubmV0LzI2MDM5Y2NlLTQ4OWQtNDAwMi04MjkzLTViMGM1MTM0ZWFjYi8iLAogICJpYXQiOiAxNDkzNDIzMTY4LAogICJuYmYiOiAxNDkzNDIzMTY4LAogICJleHAiOiAxNDkzNDY2OTUxLAogICJhY3IiOiAiMSIsCiAgImFpbyI6ICJBU1FBMi84REFBQUE1NnZGVmp0WlNjNWdBVWwrY1Z0VFpyM0VvV2NvZEoveWV1S2ZqcTZRdC9NPSIsCiAgImFtciI6IFsKICAgICJwd2QiCiAgXSwKICAiYXBwaWQiOiAiNjI1MzkxYWYtYzY3NS00M2U1LThlNDQtZWRkM2UzMGNlYjE1IiwKICAiYXBwaWRhY3IiOiAiMSIsCiAgImVfZXhwIjogMzAyNjgzLAogICJmYW1pbHlfbmFtZSI6ICJUZXN0IiwKICAiZ2l2ZW5fbmFtZSI6ICJOYXZ5YSIsCiAgImlwYWRkciI6ICIxNjcuMjIwLjEuMTc3IiwKICAibmFtZSI6ICJOYXZ5YSBUZXN0IiwKICAib2lkIjogIjFjZDRiY2FjLWI4MDgtNDIzYS05ZTJmLTgyN2ZiYjFiYjczOSIsCiAgInBsYXRmIjogIjMiLAogICJwdWlkIjogIjEwMDMzRkZGQTEyRUQ3RkUiLAogICJzY3AiOiAiVXNlci5SZWFkIiwKICAic3ViIjogIjNKTUlaSWJlYTc1R2hfWHdDN2ZzX0JDc3kxa1l1ekZKLTUyVm1Zd0JuM3ciLAogICJ0aWQiOiAiMjYwMzljY2UtNDg5ZC00MDAyLTgyOTMtNWIwYzUxMzRlYWNiIiwKICAidW5pcXVlX25hbWUiOiAibmF2eWFAZGRvYmFsaWFub3V0bG9vay5vbm1pY3Jvc29mdC5jb20iLAogICJ1cG4iOiAibmF2eWFAZGRvYmFsaWFub3V0bG9vay5vbm1pY3Jvc29mdC5jb20iLAogICJ1dGkiOiAieEN3ZnpoYS1QMFdKUU9MeENHZ0tBQSIsCiAgInZlciI6ICIxLjAiCn0.cqmUVjfVbqWsxJLUI1Z4FRx1mNQAHP-L0F4EMN09r8FY9bIKeO-0q1eTdP11Nkj_k4BmtaZsTcK_mUygdMqEp9AfyVyA1HYvokcgGCW_Z6DMlVGqlIU4ssEkL9abgl1REHElPhpwBFFBBenOk9iHddD1GddTn6vJbKC3qAaNM5VarjSPu50bVvCrqKNvFixTb5bbdnSz-Qr6n6ACiEimiI1aNOPR2DeKUyWBPaQcU5EAK0ef5IsVJC1yaYDlAcUYIILMDLCD9ebjsy0t9pj_7lvjzUSrbMdSCCdzCqez_MSNxrk1Nu9AecugkBYp3UVUZOIyythVrj6-sVvLZKUutQ
&requested_token_use=on_behalf_of
&scope=openid

Segundo caso: pedido de token de acesso com um certificado

Um pedido de token de acesso serviço a serviço com um certificado contém os seguintes parâmetros:

Parâmetro Tipo Description
grant_type obrigatório O tipo do pedido de token. Um pedido OBO utiliza um token de acesso JWT, pelo que o valor tem de ser urn:ietf:params:oauth:grant-type:jwt-bearer.
asserção obrigatório O valor do token utilizado no pedido.
client_id obrigatório O ID da aplicação atribuído ao serviço de chamadas durante o registo com Azure AD. Para localizar o ID da aplicação no portal do Azure, selecione Active Directory, escolha o diretório e, em seguida, selecione o nome da aplicação.
client_assertion_type obrigatório O valor tem de ser urn:ietf:params:oauth:client-assertion-type:jwt-bearer
client_assertion obrigatório Um Token Web JSON que cria e assina com o certificado que registou como credenciais para a sua aplicação. Veja as credenciais do certificado para saber mais sobre o formato de asserção e sobre como registar o certificado.
recurso obrigatório O URI do ID da aplicação do serviço de receção (recurso protegido). Para localizar o URI do ID da aplicação no portal do Azure, selecione Active Directory e selecione o diretório. Selecione o nome da aplicação, selecione Todas as definições e, em seguida, selecione Propriedades.
requested_token_use obrigatório Especifica como o pedido deve ser processado. No fluxo On-Behalf-Of, o valor tem de ser on_behalf_of.
scope obrigatório Uma lista separada por espaços de âmbitos para o pedido de token. Para o OpenID Connect, o openid do âmbito tem de ser especificado.

Estes parâmetros são quase os mesmos que com o pedido por segredo partilhado, exceto que o client_secret parameter é substituído por dois parâmetros: client_assertion_type e client_assertion.

Exemplo

O seguinte HTTP POST pede um token de acesso para a https://graph.microsoft.com API Web com um certificado. O client_id identifica o serviço que pede o token de acesso.

// line breaks for legibility only

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

grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer
&client_id=625391af-c675-43e5-8e44-edd3e30ceb15
&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer
&client_assertion=eyJhbGciOiJSUzI1NiIsIng1dCI6Imd4OHRHeXN5amNScUtqRlBuZDdSRnd2d1pJMCJ9.eyJ{a lot of characters here}M8U3bSUKKJDEg
&resource=https%3A%2F%2Fgraph.microsoft.com
&assertion=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6InowMzl6ZHNGdWl6cEJmQlZLMVRuMjVRSFlPMCIsImtpZCI6InowMzl6ZHNGdWl6cEJmQlZLMVRuMjVRSFlPMCJ9.eyJhdWQiOiJodHRwczovL2Rkb2JhbGlhbm91dGxvb2sub25taWNyb3NvZnQuY29tLzE5MjNmODYyLWU2ZGMtNDFhMy04MWRhLTgwMmJhZTAwYWY2ZCIsImlzcyI6Imh0dHBzOi8vc3RzLndpbmRvd3MubmV0LzI2MDM5Y2NlLTQ4OWQtNDAwMi04MjkzLTViMGM1MTM0ZWFjYi8iLCJpYXQiOjE0OTM0MjMxNTIsIm5iZiI6MTQ5MzQyMzE1MiwiZXhwIjoxNDkzNDY2NjUyLCJhY3IiOiIxIiwiYWlvIjoiWTJaZ1lCRFF2aTlVZEc0LzM0L3dpQndqbjhYeVp4YmR1TFhmVE1QeG8yYlN2elgreHBVQSIsImFtciI6WyJwd2QiXSwiYXBwaWQiOiJiMzE1MDA3OS03YmViLTQxN2YtYTA2YS0zZmRjNzhjMzI1NDUiLCJhcHBpZGFjciI6IjAiLCJlX2V4cCI6MzAyNDAwLCJmYW1pbHlfbmFtZSI6IlRlc3QiLCJnaXZlbl9uYW1lIjoiTmF2eWEiLCJpcGFkZHIiOiIxNjcuMjIwLjEuMTc3IiwibmFtZSI6Ik5hdnlhIFRlc3QiLCJvaWQiOiIxY2Q0YmNhYy1iODA4LTQyM2EtOWUyZi04MjdmYmIxYmI3MzkiLCJwbGF0ZiI6IjMiLCJzY3AiOiJ1c2VyX2ltcGVyc29uYXRpb24iLCJzdWIiOiJEVXpYbkdKMDJIUk0zRW5pbDFxdjZCakxTNUllQy0tQ2ZpbzRxS1MzNEc4IiwidGlkIjoiMjYwMzljY2UtNDg5ZC00MDAyLTgyOTMtNWIwYzUxMzRlYWNiIiwidW5pcXVlX25hbWUiOiJuYXZ5YUBkZG9iYWxpYW5vdXRsb29rLm9ubWljcm9zb2Z0LmNvbSIsInVwbiI6Im5hdnlhQGRkb2JhbGlhbm91dGxvb2sub25taWNyb3NvZnQuY29tIiwidmVyIjoiMS4wIn0.R-Ke-XO7lK0r5uLwxB8g5CrcPAwRln5SccJCfEjU6IUqpqcjWcDzeDdNOySiVPDU_ZU5knJmzRCF8fcjFtPsaA4R7vdIEbDuOur15FXSvE8FvVSjP_49OH6hBYqoSUAslN3FMfbO6Z8YfCIY4tSOB2I6ahQ_x4ZWFWglC3w5mK-_4iX81bqi95eV4RUKefUuHhQDXtWhrSgIEC0YiluMvA4TnaJdLq_tWXIc4_Tq_KfpkvI004ONKgU7EAMEr1wZ4aDcJV2yf22gQ1sCSig6EGSTmmzDuEPsYiyd4NhidRZJP4HiiQh-hePBQsgcSgYGvz9wC6n57ufYKh2wm_Ti3Q
&requested_token_use=on_behalf_of
&scope=openid

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

Uma resposta com êxito é uma resposta JSON OAuth 2.0 com os seguintes parâmetros:

Parâmetro Description
token_type Indica o valor do tipo de token. O único tipo que Azure AD suporta é Portador. Para obter mais informações sobre tokens de portador, veja OAuth 2.0 Authorization Framework: Bearer Token Usage (RFC 6750).
scope O âmbito de acesso concedido no token.
expires_in O período de tempo durante o qual o token de acesso é válido (em segundos).
expires_on A hora em que o token de acesso expira. A data é representada como o número de segundos de 1970-01-01T0:0:0Z UTC até à hora de expiração. Este valor é utilizado para determinar a duração dos tokens em cache.
recurso O URI do ID da aplicação do serviço de receção (recurso protegido).
access_token O token de acesso pedido. O serviço de chamadas pode utilizar este token para autenticar no serviço de receção.
id_token O token de ID pedido. O serviço de chamadas pode utilizar este token para verificar a identidade do utilizador e iniciar uma sessão com o utilizador.
refresh_token O token de atualização do token de acesso pedido. O serviço de chamadas pode utilizar este token para pedir outro token de acesso depois de o token de acesso atual expirar.

Exemplo de resposta com êxito

O exemplo seguinte mostra uma resposta bem-sucedida a um pedido de um token de acesso para a https://graph.microsoft.com API Web.

{
    "token_type":"Bearer",
    "scope":"User.Read",
    "expires_in":"43482",
    "ext_expires_in":"302683",
    "expires_on":"1493466951",
    "not_before":"1493423168",
    "resource":"https://graph.microsoft.com",
    "access_token":"eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6InowMzl6ZHNGdWl6cEJmQlZLMVRuMjVRSFlPMCIsImtpZCI6InowMzl6ZHNGdWl6cEJmQlZLMVRuMjVRSFlPMCJ9.eyJhdWQiOiJodHRwczovL2dyYXBoLndpbmRvd3MubmV0IiwiaXNzIjoiaHR0cHM6Ly9zdHMud2luZG93cy5uZXQvMjYwMzljY2UtNDg5ZC00MDAyLTgyOTMtNWIwYzUxMzRlYWNiLyIsImlhdCI6MTQ5MzQyMzE2OCwibmJmIjoxNDkzNDIzMTY4LCJleHAiOjE0OTM0NjY5NTEsImFjciI6IjEiLCJhaW8iOiJBU1FBMi84REFBQUE1NnZGVmp0WlNjNWdBVWwrY1Z0VFpyM0VvV2NvZEoveWV1S2ZqcTZRdC9NPSIsImFtciI6WyJwd2QiXSwiYXBwaWQiOiI2MjUzOTFhZi1jNjc1LTQzZTUtOGU0NC1lZGQzZTMwY2ViMTUiLCJhcHBpZGFjciI6IjEiLCJlX2V4cCI6MzAyNjgzLCJmYW1pbHlfbmFtZSI6IlRlc3QiLCJnaXZlbl9uYW1lIjoiTmF2eWEiLCJpcGFkZHIiOiIxNjcuMjIwLjEuMTc3IiwibmFtZSI6Ik5hdnlhIFRlc3QiLCJvaWQiOiIxY2Q0YmNhYy1iODA4LTQyM2EtOWUyZi04MjdmYmIxYmI3MzkiLCJwbGF0ZiI6IjMiLCJwdWlkIjoiMTAwMzNGRkZBMTJFRDdGRSIsInNjcCI6IlVzZXIuUmVhZCIsInN1YiI6IjNKTUlaSWJlYTc1R2hfWHdDN2ZzX0JDc3kxa1l1ekZKLTUyVm1Zd0JuM3ciLCJ0aWQiOiIyNjAzOWNjZS00ODlkLTQwMDItODI5My01YjBjNTEzNGVhY2IiLCJ1bmlxdWVfbmFtZSI6Im5hdnlhQGRkb2JhbGlhbm91dGxvb2sub25taWNyb3NvZnQuY29tIiwidXBuIjoibmF2eWFAZGRvYmFsaWFub3V0bG9vay5vbm1pY3Jvc29mdC5jb20iLCJ1dGkiOiJ4Q3dmemhhLVAwV0pRT0x4Q0dnS0FBIiwidmVyIjoiMS4wIn0.cqmUVjfVbqWsxJLUI1Z4FRx1mNQAHP-L0F4EMN09r8FY9bIKeO-0q1eTdP11Nkj_k4BmtaZsTcK_mUygdMqEp9AfyVyA1HYvokcgGCW_Z6DMlVGqlIU4ssEkL9abgl1REHElPhpwBFFBBenOk9iHddD1GddTn6vJbKC3qAaNM5VarjSPu50bVvCrqKNvFixTb5bbdnSz-Qr6n6ACiEimiI1aNOPR2DeKUyWBPaQcU5EAK0ef5IsVJC1yaYDlAcUYIILMDLCD9ebjsy0t9pj_7lvjzUSrbMdSCCdzCqez_MSNxrk1Nu9AecugkBYp3UVUZOIyythVrj6-sVvLZKUutQ",
    "refresh_token":"AQABAAAAAABnfiG-mA6NTae7CdWW7QfdjKGu9-t1scy_TDEmLi4eLQMjJGt_nAoVu6A4oSu1KsRiz8XyQIPKQxSGfbf2FoSK-hm2K8TYzbJuswYusQpJaHUQnSqEvdaCeFuqXHBv84wjFhuanzF9dQZB_Ng5za9xKlUENrNtlq9XuLNVKzxEyeUM7JyxzdY7JiEphWImwgOYf6II316d0Z6-H3oYsFezf4Xsjz-MOBYEov0P64UaB5nJMvDyApV-NWpgklLASfNoSPGb67Bc02aFRZrm4kLk-xTl6eKE6hSo0XU2z2t70stFJDxvNQobnvNHrAmBaHWPAcC3FGwFnBOojpZB2tzG1gLEbmdROVDp8kHEYAwnRK947Py12fJNKExUdN0njmXrKxNZ_fEM33LHW1Tf4kMX_GvNmbWHtBnIyG0w5emb-b54ef5AwV5_tGUeivTCCysgucEc-S7G8Cz0xNJ_BOiM_4bAv9iFmrm9STkltpz0-Tftg8WKmaJiC0xXj6uTf4ZkX79mJJIuuM7XP4ARIcLpkktyg2Iym9jcZqymRkGH2Rm9sxBwC4eeZXM7M5a7TJ-5CqOdfuE3sBPq40RdEWMFLcrAzFvP0VDR8NKHIrPR1AcUruat9DETmTNJukdlJN3O41nWdZOVoJM-uKN3uz2wQ2Ld1z0Mb9_6YfMox9KTJNzRzcL52r4V_y3kB6ekaOZ9wQ3HxGBQ4zFt-2U0mSszIAA",
    "id_token":"eyJ0eXAiOiJKV1QiLCJhbGciOiJub25lIn0.eyJhdWQiOiI2MjUzOTFhZi1jNjc1LTQzZTUtOGU0NC1lZGQzZTMwY2ViMTUiLCJpc3MiOiJodHRwczovL3N0cy53aW5kb3dzLm5ldC8yNjAzOWNjZS00ODlkLTQwMDItODI5My01YjBjNTEzNGVhY2IvIiwiaWF0IjoxNDkzNDIzMTY4LCJuYmYiOjE0OTM0MjMxNjgsImV4cCI6MTQ5MzQ2Njk1MSwiYW1yIjpbInB3ZCJdLCJmYW1pbHlfbmFtZSI6IlRlc3QiLCJnaXZlbl9uYW1lIjoiTmF2eWEiLCJpcGFkZHIiOiIxNjcuMjIwLjEuMTc3IiwibmFtZSI6Ik5hdnlhIFRlc3QiLCJvaWQiOiIxY2Q0YmNhYy1iODA4LTQyM2EtOWUyZi04MjdmYmIxYmI3MzkiLCJwbGF0ZiI6IjMiLCJzdWIiOiJEVXpYbkdKMDJIUk0zRW5pbDFxdjZCakxTNUllQy0tQ2ZpbzRxS1MzNEc4IiwidGlkIjoiMjYwMzljY2UtNDg5ZC00MDAyLTgyOTMtNWIwYzUxMzRlYWNiIiwidW5pcXVlX25hbWUiOiJuYXZ5YUBkZG9iYWxpYW5vdXRsb29rLm9ubWljcm9zb2Z0LmNvbSIsInVwbiI6Im5hdnlhQGRkb2JhbGlhbm91dGxvb2sub25taWNyb3NvZnQuY29tIiwidXRpIjoieEN3ZnpoYS1QMFdKUU9MeENHZ0tBQSIsInZlciI6IjEuMCJ9."
}

Exemplo de resposta a erros

O ponto final do token Azure AD devolve uma resposta de erro quando tenta adquirir um token de acesso para uma API a jusante definida com uma política de Acesso Condicional (por exemplo, autenticação multifator). O serviço de camada média deve apresentar este erro à aplicação cliente para que a aplicação cliente possa fornecer a interação do utilizador para satisfazer a política de Acesso Condicional.

{
    "error":"interaction_required",
    "error_description":"AADSTS50079: Due to a configuration change made by your administrator, or because you moved to a new location, you must enroll in multi-factor authentication to access 'bf8d80f9-9098-4972-b203-500f535113b1'.\r\nTrace ID: b72a68c3-0926-4b8e-bc35-3150069c2800\r\nCorrelation ID: 73d656cf-54b1-4eb2-b429-26d8165a52d7\r\nTimestamp: 2017-05-01 22:43:20Z",
    "error_codes":[50079],
    "timestamp":"2017-05-01 22:43:20Z",
    "trace_id":"b72a68c3-0926-4b8e-bc35-3150069c2800",
    "correlation_id":"73d656cf-54b1-4eb2-b429-26d8165a52d7",
    "claims":"{\"access_token\":{\"polids\":{\"essential\":true,\"values\":[\"9ab03e19-ed42-4168-b6b7-7001fb3e933a\"]}}}"
}

Utilizar o token de acesso para aceder ao recurso protegido

O serviço de camada média pode utilizar o token de acesso adquirido para fazer pedidos autenticados à API Web a jusante ao definir o token no Authorization cabeçalho.

Exemplo

GET /me?api-version=2013-11-08 HTTP/1.1
Host: graph.microsoft.com
Authorization: Bearer eyJ0eXAiO ... 0X2tnSQLEANnSPHY0gKcgw

Asserções SAML obtidas com um fluxo OBO OAuth2.0

Alguns serviços Web baseados em OAuth precisam de aceder a outras APIs de serviço Web que aceitam asserções SAML em fluxos não interativos. O Azure Active Directory pode fornecer uma asserção SAML em resposta a um fluxo On-Behalf-Of que utiliza um serviço Web baseado em SAML como recurso de destino.

Nota

Esta é uma extensão não padrão para o fluxo On-Behalf-Of do OAuth 2.0 que permite que uma aplicação baseada em OAuth2 aceda a pontos finais da API do serviço Web que consomem tokens SAML.

Dica

Quando chama um serviço Web protegido por SAML a partir de uma aplicação Web de front-end, pode simplesmente chamar a API e iniciar um fluxo de autenticação interativo normal com a sessão existente do utilizador. Só precisa de utilizar um fluxo OBO quando uma chamada serviço a serviço requer um token SAML para fornecer contexto de utilizador.

Obter um token SAML com um pedido OBO com um segredo partilhado

Um pedido de serviço a serviço para uma asserção SAML contém os seguintes parâmetros:

Parâmetro Tipo Description
grant_type obrigatório O tipo do pedido de token. Para um pedido que utiliza um JWT, o valor tem de ser urn:ietf:params:oauth:grant-type:jwt-bearer.
asserção obrigatório O valor do token de acesso utilizado no pedido.
client_id obrigatório O ID da aplicação atribuído ao serviço de chamadas durante o registo com Azure AD. Para localizar o ID da aplicação no portal do Azure, selecione Active Directory, selecione o diretório e, em seguida, selecione o nome da aplicação.
client_secret obrigatório A chave registada para o serviço de chamadas no Azure AD. Este valor deveria ter sido anotado no momento do registo.
recurso obrigatório O URI do ID da aplicação do serviço de receção (recurso protegido). Este é o recurso que será a Audiência do token SAML. Para localizar o URI do ID da aplicação no portal do Azure, selecione Active Directory e selecione o diretório. Selecione o nome da aplicação, selecione Todas as definições e, em seguida, selecione Propriedades.
requested_token_use obrigatório Especifica como o pedido deve ser processado. No fluxo Em Nome de, o valor tem de ser on_behalf_of.
requested_token_type obrigatório Especifica o tipo de token pedido. O valor pode ser urn:ietf:params:oauth:token-type:saml2 ou urn:ietf:params:oauth:token-type:saml1 consoante os requisitos do recurso acedido.

A resposta contém um token SAML codificado em UTF8 e Base64url.

  • SubjectConfirmationData para uma asserção SAML proveniente de uma chamada OBO: se a aplicação de destino exigir um valor de destinatário em SubjectConfirmationData, o valor tem de ser um URL de Resposta não universal na configuração da aplicação de recursos.

  • O nó SubjectConfirmationData: o nó não pode conter um atributo InResponseTo , uma vez que não faz parte de uma resposta SAML. A aplicação que recebe o token SAML tem de ser capaz de aceitar a asserção SAML sem um atributo InResponseTo .

  • Consentimento: tem de ter sido concedido consentimento para receber um token SAML que contenha dados de utilizador num fluxo OAuth. Para obter informações sobre permissões e obter o consentimento do administrador, veja Permissões e consentimento no ponto final do Azure Active Directory v1.0.

Resposta com asserção SAML

Parâmetro Description
token_type Indica o valor do tipo de token. O único tipo que Azure AD suporta é o Portador. Para obter mais informações sobre tokens de portador, veja OAuth 2.0 Authorization Framework: Bearer Token Usage (RFC 6750).
scope O âmbito de acesso concedido no token.
expires_in O período de tempo em que o token de acesso é válido (em segundos).
expires_on A hora em que o token de acesso expira. A data é representada como o número de segundos entre 1970 e 01-01T0:0:0Z UTC até à hora de expiração. Este valor é utilizado para determinar a duração dos tokens em cache.
recurso O URI do ID da aplicação do serviço de receção (recurso protegido).
access_token O parâmetro que devolve a asserção SAML.
refresh_token O token de atualização. O serviço de chamadas pode utilizar este token para pedir outro token de acesso após a expiração da asserção SAML atual.
  • token_type: Portador
  • expires_in: 3296
  • ext_expires_in: 0
  • expires_on: 1529627844
  • recurso: https://api.contoso.com
  • access_token: <asserção SAML>
  • issued_token_type: urn:ietf:params:oauth:token-type:saml2
  • refresh_token: <Atualizar token>

Limitações do cliente

Os clientes públicos com URLs de resposta universal não podem utilizar um id_token para fluxos OBO. No entanto, um cliente confidencial ainda pode resgatar tokens de acesso adquiridos através do fluxo de concessão implícito, mesmo que o cliente público tenha um URI de redirecionamento de carateres universais registado.

Passos seguintes

Saiba mais sobre o protocolo OAuth 2.0 e outra forma de efetuar a autenticação serviço a serviço que utiliza credenciais de cliente: