Solicitar um token de acesso no Azure Active Directory B2C

  • Artigo

Um token de acesso contém declarações que você pode usar no Azure Active Directory B2C (Azure AD B2C) para identificar as permissões concedidas às APIs. Para chamar um servidor de recursos, a solicitação HTTP deve incluir um token de acesso. Um token de acesso é indicado como access_token nas respostas do Azure AD B2C.

Este artigo mostra como solicitar um token de acesso para um aplicativo e uma API da Web. Para obter mais informações sobre os tokens no Azure AD B2C, consulte a visão geral dos tokens no Azure Active Directory B2C.

Observação

Não há suporte para cadeias da API Web (On-Behalf-Of) no Azure AD B2C – Muitas arquiteturas incluem uma API Web que precisa chamar outra API Web downstream, ambas protegidas pelo Azure AD B2C. Esse cenário é comum em clientes que têm um back-end de API da Web que, por sua vez, chama um outro serviço. Este cenário de API Web encadeada pode ter suporte usando a concessão de Credencial de Portador JWT do OAuth 2.0, também conhecida como fluxo Em nome de. No entanto, o fluxo Em Nome de não está implementado atualmente no Azure AD B2C. Embora o On-Behalf-Of funcione para aplicativos registrados no Microsoft Entra ID, ele não funciona para aplicativos registrados no Azure AD B2C, independentemente do locatário (Microsoft Entra ID ou Azure AD B2C) que está emitindo os tokens.

Pré-requisitos

Escopos

Os escopos fornecem uma maneira de gerenciar as permissões em recursos protegidos. Ao solicitar um token de acesso, o aplicativo cliente precisa especificar as permissões desejadas no parâmetro scope da solicitação. Por exemplo, para especificar o Valor do escopo de read para a API que tem o URI da ID do aplicativo de https://contoso.onmicrosoft.com/api, o escopo seria https://contoso.onmicrosoft.com/api/read.

Escopos são usados pela API Web para implementar o controle de acesso com base em escopo. Por exemplo, os usuários da API Web podem ter tanto acesso de leitura quanto de gravação ou somente acesso de leitura. Para adquirir várias permissões na mesma solicitação, você pode adicionar várias entradas separadas por espaços no único parâmetro scope da solicitação.

O exemplo a seguir mostra os escopos decodificados em uma URL:

scope=https://contoso.onmicrosoft.com/api/read openid offline_access

O exemplo a seguir mostra os escopos codificados em uma URL:

scope=https%3A%2F%2Fcontoso.onmicrosoft.com%2Fapi%2Fread%20openid%20offline_access

Se você solicitar mais escopos do que o permitido para o aplicativo cliente, a chamada terá sucesso se pelo menos uma permissão for concedida. A declaração scp no token de acesso resultante é preenchida apenas com as permissões que foram concedidas com êxito.

Escopos do OpenID Connect

O padrão de OpenID Connect especifica vários valores especiais de escopo. Os seguintes escopos declaram a permissão para acessar o perfil do usuário:

  • openid - Solicita um token de ID.
  • offline_access - Solicita um token de atualização usando fluxos de Código de autenticação.
  • 00000000-0000-0000-0000-000000000000 - O uso da ID do cliente como o escopo indica que seu aplicativo precisa de um token de acesso que possa ser usado em relação a seu próprio serviço ou API Web, representado pela mesma ID de cliente.

Se o parâmetro response_type em uma solicitação /authorize incluir token, o parâmetro scope deverá incluir o escopo de pelo menos um recurso diferente de openid e offline_access que será concedido. Caso contrário, a solicitação /authorize será rejeitada.

Solicitar um token

Para solicitar um token de acesso, é necessário um código de autorização. Veja a seguir um exemplo de uma solicitação para o ponto de extremidade /authorize de um código de autorização:

GET https://<tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/<policy-name>/oauth2/v2.0/authorize?
client_id=<application-ID>
&nonce=anyRandomValue
&redirect_uri=https://jwt.ms
&scope=<application-ID-URI>/<scope-name>
&response_type=code

Substitua os valores na cadeia de caracteres de consulta da seguinte maneira:

  • <tenant-name> – O nome do seu locatário do Azure AD B2C. Se você estiver usando um domínio personalizado, substitua tenant-name.b2clogin.com pelo seu domínio, como contoso.com.
  • <policy-name> – O nome da sua política personalizada ou o fluxo de usuário.
  • <application-ID> – O identificador de aplicativo do aplicativo cliente que você registrou para oferecer suporte ao fluxo de usuário.
  • <application-ID-URI> - O URI do identificador de aplicativo que você definiu na folha Expor uma API do aplicativo cliente.
  • <scope-name> - O nome do escopo que você adicionou na folha Expor uma API do aplicativo cliente.
  • <redirect-uri> – O URI de redirecionamento que você inseriu ao registrar o aplicativo cliente.

Para ter uma ideia de como a solicitação funciona, colar a solicitação em seu navegador e execute-a.

Essa é a parte interativa do fluxo, na qual você realiza uma ação. Você precisará concluir o fluxo de trabalho do fluxo do usuário. Isso pode envolver a inserção do seu nome de usuário e da senha em um formulário de entrada ou qualquer outra quantidade de etapas. As etapas que você concluir dependerão de como o fluxo do usuário é definido.

A resposta com o código de autorização deve ser semelhante a este exemplo:

https://jwt.ms/?code=eyJraWQiOiJjcGltY29yZV8wOTI1MjAxNSIsInZlciI6IjEuMC...

Depois de receber o código de autorização com êxito, use-o para solicitar um token de acesso. Os parâmetros estão no corpo da solicitação HTTP POST:

POST <tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/<policy-name>/oauth2/v2.0/token HTTP/1.1
Host: <tenant-name>.b2clogin.com
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&client_id=<application-ID>
&scope=<application-ID-URI>/<scope-name>
&code=eyJraWQiOiJjcGltY29yZV8wOTI1MjAxNSIsInZlciI6IjEuMC...
&redirect_uri=https://jwt.ms
&client_secret=2hMG2-_:y12n10vwH...

Se quiser testar essa solicitação HTTP POST, use qualquer cliente HTTP, como o Microsoft PowerShell ou o Postman.

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

{
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6Ilg1ZVhrN...",
    "token_type": "Bearer",
    "not_before": 1549647431,
    "expires_in": 3600,
    "expires_on": 1549651031,
    "resource": "f2a76e08-93f2-4350-833c-965c02483b11",
    "profile_info": "eyJ2ZXIiOiIxLjAiLCJ0aWQiOiJjNjRhNGY3ZC0zMDkxLTRjNzMtYTcyMi1hM2YwNjk0Z..."
}

Ao usar https://jwt.ms para examinar o token de acesso retornado, você verá algo semelhante ao exemplo a seguir:

{
  "typ": "JWT",
  "alg": "RS256",
  "kid": "X5eXk4xyojNFum1kl2Ytv8dl..."
}.{
  "iss": "https://contoso0926tenant.b2clogin.com/c64a4f7d-3091-4c73-a7.../v2.0/",
  "exp": 1549651031,
  "nbf": 1549647431,
  "aud": "f2a76e08-93f2-4350-833c-965...",
  "oid": "1558f87f-452b-4757-bcd1-883...",
  "sub": "1558f87f-452b-4757-bcd1-883...",
  "name": "David",
  "tfp": "B2C_1_signupsignin1",
  "nonce": "anyRandomValue",
  "scp": "read",
  "azp": "38307aee-303c-4fff-8087-d8d2...",
  "ver": "1.0",
  "iat": 1549647431
}.[Signature]

Próximas etapas