Partilhar via

Solicitar um token de acesso no Azure Ative Directory B2C

Importante

A partir de 1º de maio de 2025, o Azure AD B2C não estará mais disponível para compra para novos clientes. Saiba mais nas nossas Perguntas Frequentes.

Um token de acesso contém declarações que você pode usar no Azure Ative Directory B2C (Azure AD B2C) para identificar as permissões concedidas às suas 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 Web e uma API da Web. Para obter mais informações sobre tokens no Azure AD B2C, consulte a visão geral de tokens no Azure Ative Directory B2C.

Observação

Cadeias de API Web (On-Behalf-Of) não são suportadas pelo 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 outro serviço. O cenário de API web encadeada pode ser suportado usando a concessão de credenciais do portador JWT OAuth 2.0, também conhecida como fluxo On-Behalf-Of. No entanto, o fluxo "On-Behalf-Of" não está atualmente implementado 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

Alcances

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

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

O exemplo a seguir mostra escopos decodificados em uma URL:

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

O exemplo a seguir mostra 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 concedido para seu aplicativo cliente, a chamada será bem-sucedida 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 OpenID Connect especifica vários valores especiais de escopo. Os escopos a seguir representam 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 - Usar a ID do cliente como escopo indica que seu aplicativo precisa de um token de acesso que possa ser usado em seu próprio serviço ou API da Web, representado pelo mesmo ID do cliente.

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

Solicite um token

Para solicitar um token de acesso, você precisa de um código de autorização. Segue-se um exemplo de um pedido ao /authorize endpoint para 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 inquilino do Azure AD B2C. Se estiver a utilizar 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 fluxo de usuário.
  • <application-ID> - O identificador de aplicação da aplicação Web que registou para suportar o fluxo de utilizadores.
  • <application-ID-URI> - O URI do identificador da aplicação que definiu no painel Expor uma API da aplicação cliente.
  • <scope-name> - O nome do escopo que adicionou na seção Expor uma API do aplicativo cliente.
  • <redirect-uri> - O URI de redirecionamento que você inseriu quando registrou o aplicativo cliente.

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

Esta é a parte interativa do fluxo, onde se age. Você deve completar o fluxo de trabalho do usuário. Isso pode envolver a inserção de seu nome de usuário e senha em um formulário de login ou qualquer outro número de etapas. As etapas concluídas dependem de como o fluxo de 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 com êxito o código de autorização, você pode usá-lo 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, você pode usar qualquer cliente HTTP, como o Microsoft PowerShell.

Uma resposta de token bem-sucedida 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 que foi 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óximos passos

  • Last updated on