Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
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.
Você pode usar a concessão de código de autorização OAuth 2.0 em aplicativos instalados em um dispositivo para obter acesso a recursos protegidos, como APIs da Web. Usando a implementação do Azure Ative Directory B2C (Azure AD B2C) do OAuth 2.0, você pode adicionar tarefas de inscrição, entrada e outras tarefas de gerenciamento de identidade aos seus aplicativos de página única, móveis e de área de trabalho. Neste artigo, descrevemos como enviar e receber mensagens HTTP sem usar bibliotecas de código aberto. Este artigo é independente do idioma. Sempre que possível, recomendamos que utilize as Bibliotecas de Autenticação Microsoft (MSAL) suportadas. Dê uma olhada nos aplicativos de exemplo que usam o MSAL.
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. Você pode usá-lo para autenticação e autorização na maioria dos tipos de aplicativos, incluindo aplicativos Web, aplicativos de página única e aplicativos instalados nativamente. Você pode usar o fluxo de código de autorização do OAuth 2.0 para adquirir tokens de acesso e atualizar tokens para seus aplicativos, que podem ser usados para acessar recursos protegidos por um servidor de autorização. O token de atualização permite que o cliente adquira novos tokens de acesso (e atualização) assim que o token de acesso expirar, normalmente após uma hora.
Este artigo se concentra no fluxo de código de autorização OAuth 2.0 de clientes públicos . Um cliente público é qualquer aplicativo cliente que não pode ser confiável para manter com segurança a integridade de uma senha secreta. Isso inclui aplicativos de página única, aplicativos móveis, aplicativos de desktop e, essencialmente, qualquer aplicativo que não seja executado em um servidor.
Observação
Para adicionar o gerenciamento de identidades a um aplicativo Web usando o Azure AD B2C, use o OpenID Connect em vez do OAuth 2.0.
O Azure AD B2C estende os fluxos OAuth 2.0 padrão para fazer mais do que a simples autenticação e autorização. Ele introduz o fluxo do usuário. Com fluxos de usuário, você pode usar o OAuth 2.0 para adicionar experiências de usuário ao seu aplicativo, como inscrição, entrada e gerenciamento de perfil. Os provedores de identidade que usam o protocolo OAuth 2.0 incluem Amazon, Microsoft Entra ID, Facebook, GitHub, Google e LinkedIn.
Para tentar as solicitações HTTP neste artigo:
- Substitua
{tenant}pelo nome do seu locatário do Azure AD B2C. - Substitua
00001111-aaaa-2222-bbbb-3333cccc4444pela ID do aplicativo de um aplicativo que você registrou anteriormente em seu locatário do Azure AD B2C. - Substitua
{policy}pelo nome de uma política que você criou em seu locatário, por exemplob2c_1_sign_in.
Redirecionar a configuração de URI necessária para aplicativos de página única
O fluxo de código de autorização para aplicativos de página única requer alguma configuração adicional. Siga as instruções para criar seu aplicativo de página única para marcar corretamente seu URI de redirecionamento como habilitado para CORS. Para atualizar um URI de redirecionamento existente para ativar o CORS, pode clicar no prompt de migração na seção "Web" da guia Autenticação de registro do aplicativo. Como alternativa, pode abrir o editor de manifesto de registros do aplicativo e definir o campo type para o seu URI de redirecionamento como spa na seção replyUrlsWithType.
O spa tipo de redirecionamento é compatível com o fluxo implícito. As aplicações que atualmente usam o fluxo implícito para obter tokens podem ser alteradas para o tipo de URI de redirecionamento spa sem problemas e continuar a usar o fluxo implícito.
1. Obtenha um código de autorização
O fluxo de código de autorização começa quando o cliente direciona o utilizador para o endpoint /authorize. Esta é a parte interativa do fluxo, onde o usuário entra em ação. Nessa solicitação, o cliente indica no scope parâmetro as permissões que precisa adquirir do usuário. Os exemplos a seguir (com quebras de linha para legibilidade) mostram como adquirir um código de autorização. Se você estiver testando essa solicitação HTTP GET, use seu navegador.
GET https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/authorize?
client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&response_type=code
&redirect_uri=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob
&response_mode=query
&scope=00001111-aaaa-2222-bbbb-3333cccc4444%20offline_access%20https://{tenant-name}/{app-id-uri}/{scope}
&state=arbitrary_data_you_can_receive_in_the_response
&code_challenge=YTFjNjI1OWYzMzA3MTI4ZDY2Njg5M2RkNmVjNDE5YmEyZGRhOGYyM2IzNjdmZWFhMTQ1ODg3NDcxY2Nl
&code_challenge_method=S256
| Parâmetro | Necessário? | Descrição |
|---|---|---|
| {inquilino} | Obrigatório | Nome do inquilino do Azure AD B2C |
| {política} | Obrigatório | O fluxo de utilizador que será executado. Especifique o nome de um fluxo de usuário que você criou em seu locatário do Azure AD B2C. Por exemplo: b2c_1_sign_in, b2c_1_sign_up, ou b2c_1_edit_profile. |
| ID do cliente | Obrigatório | A ID do aplicativo atribuída ao seu aplicativo no portal do Azure. |
| tipo_de_resposta | Obrigatório | O tipo de resposta, que deve incluir code no fluxo de código de autorização. Você pode receber um token de ID se incluí-lo no tipo de resposta, como code+id_token, e, nesse caso, o escopo precisa incluir openid. |
| uri_de_redirecionamento | Obrigatório | O URI de redirecionamento do seu aplicativo, onde as respostas de autenticação são enviadas e recebidas pelo seu aplicativo. Ele deve corresponder exatamente a um dos URIs de redirecionamento que você registrou no portal, exceto que ele deve ser codificado por URL. |
| Alcance | Obrigatório | Uma lista de escopos separados por espaço. O openid escopo indica uma permissão para iniciar sessão do utilizador e obter dados sobre o utilizador na forma de tokens de identificação. O offline_access escopo é opcional para aplicativos Web. Ele indica que seu aplicativo precisa de um token de atualização para acesso estendido aos recursos. A id do cliente indica que o token emitido se destina ao uso pelo cliente registrado do Azure AD B2C. O https://{tenant-name}/{app-id-uri}/{scope} indica uma permissão para recursos protegidos, como uma API da Web. Para obter mais informações, consulte Solicitar um token de acesso. |
| modo_de_resposta | Recomendado | O método que você usa para enviar o código de autorização resultante de volta para seu aplicativo. Pode ser query, form_postou fragment. |
| Estado | Recomendado | Um valor incluído na solicitação que pode ser uma cadeia de caracteres de qualquer conteúdo que você deseja usar. Normalmente, um valor exclusivo gerado aleatoriamente é 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. Por exemplo, a página em que o usuário estava ou o fluxo de usuário que estava sendo executado. |
| Sugestão | Opcional | O tipo de interação do usuário necessária. Atualmente, o único valor válido é login, que força o usuário a inserir suas credenciais nessa solicitação. O logon único não terá efeito. |
| desafio de código | recomendado / obrigatório | Usado para garantir concessões de código de autorização via Proof Key for Code Exchange (PKCE). Obrigatório se code_challenge_method estiver incluído. Você precisa adicionar lógica em seu aplicativo para gerar o code_verifier e code_challenge. O code_challenge é um hash SHA256 codificado por URL Base64 do code_verifier. Você armazena o code_verifier em seu aplicativo para uso posterior e envia o code_challenge junto com a solicitação de autorização. Para obter mais informações, consulte a RFC PKCE. Isso agora é recomendado para todos os tipos de aplicativos - aplicativos nativos, SPAs e clientes confidenciais, como aplicativos Web. |
code_challenge_method |
recomendado / obrigatório | O método usado para codificar o code_verifier para o code_challenge parâmetro. Isso DEVE ser S256, mas a especificação permite o uso de plain se, por algum motivo, o cliente não puder suportar SHA256. Se você excluir o code_challenge_method, mas ainda incluir o code_challenge, então o code_challenge é assumido como texto sem formatação. A plataforma de identidade da Microsoft suporta tanto plain quanto S256. Para obter mais informações, consulte a RFC PKCE. Isso é necessário para aplicativos de página única que usam o fluxo de código de autorização. |
| login_hint | Não | Pode ser utilizado para preencher antecipadamente o campo de nome de utilizador da página de início de sessão. Para obter mais informações, consulte Pré-preencher o nome de entrada. |
| sugestão_de_domínio | Não | Fornece uma dica para o Azure AD B2C sobre o provedor de identidade social que deve ser usado para entrar. Se um valor válido for incluído, o usuário irá diretamente para a página de entrada do provedor de identidade. Para obter mais informações, consulte Redirecionar o login para um provedor social. |
| Parâmetros personalizados | Não | Parâmetros personalizados que podem ser usados com políticas personalizadas. Por exemplo, URI dinâmico de conteúdo de página personalizada ou resolvedores de declaração de chave-valor. |
Neste ponto, o utilizador é solicitado a concluir o fluxo de trabalho. Isso pode envolver o usuário digitando seu nome de usuário e senha, entrando com uma identidade social, inscrevendo-se no diretório ou qualquer outro número de etapas. As ações do usuário dependem de como o fluxo do usuário é definido.
Depois que o usuário conclui o fluxo de usuário, a ID do Microsoft Entra retorna uma resposta ao seu aplicativo no valor usado para redirect_uri. Ele usa o método especificado no response_mode parâmetro. A resposta é exatamente a mesma para cada um dos cenários de ação do usuário, independentemente do fluxo de usuário que foi executado.
Uma resposta bem-sucedida que usa response_mode=query tem esta aparência:
GET urn:ietf:wg:oauth:2.0:oob?
code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq... // the authorization_code, truncated
&state=arbitrary_data_you_can_receive_in_the_response // the value provided in the request
| Parâmetro | Descrição |
|---|---|
| código | O código de autorização que o aplicativo solicitou. O aplicativo pode usar o código de autorização para solicitar um token de acesso para um recurso de destino. Os códigos de autorização são de curta duração. Normalmente, expiram após cerca de 10 minutos. |
| Estado | Veja a descrição completa na tabela na seção anterior. Se um state parâmetro for incluído na solicitação, o mesmo valor deverá aparecer na resposta. O aplicativo deve verificar se os state valores na solicitação e na resposta são idênticos. |
As respostas de erro também podem ser enviadas para o URI de redirecionamento para que o aplicativo possa manipulá-las adequadamente:
GET urn:ietf:wg:oauth:2.0:oob?
error=access_denied
&error_description=The+user+has+cancelled+entering+self-asserted+information
&state=arbitrary_data_you_can_receive_in_the_response
| Parâmetro | Descrição |
|---|---|
| erro | Uma cadeia de caracteres de código de erro que você pode usar para classificar os tipos de erros que ocorrem. Você também pode usar a cadeia de caracteres para reagir a erros. |
| descrição_do_erro | Uma mensagem de erro específica que pode ajudá-lo a identificar a causa raiz de um erro de autenticação. |
| Estado | Veja a descrição completa na tabela anterior. Se um state parâmetro for incluído na solicitação, o mesmo valor deverá aparecer na resposta. O aplicativo deve verificar se os state valores na solicitação e na resposta são idênticos. |
2. Obtenha um token de acesso
Agora que adquiriu um código de autorização, pode resgatar o code por um token para o recurso pretendido, enviando uma solicitação POST para o endpoint /token. No Azure AD B2C, você pode solicitar tokens de acesso para outras APIs como de costume, especificando o(s) seu(s) escopo(s) na solicitação.
Você também pode solicitar um token de acesso para a API Web de back-end da sua aplicação seguindo a convenção de usar a ID de cliente da aplicação como o escopo solicitado (o que resultará em um token de acesso com essa ID de cliente como o "destinatário"):
POST https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/token HTTP/1.1
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code
&client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&scope=00001111-aaaa-2222-bbbb-3333cccc4444 offline_access
&code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&redirect_uri=urn:ietf:wg:oauth:2.0:oob
&code_verifier=ThisIsntRandomButItNeedsToBe43CharactersLong
| Parâmetro | Necessário? | Descrição |
|---|---|---|
| {inquilino} | Obrigatório | Nome do inquilino do Azure AD B2C |
| {política} | Obrigatório | O fluxo de usuário que foi usado para adquirir o código de autorização. Não é possível usar um fluxo de usuário diferente nessa solicitação. |
| ID do cliente | Obrigatório | A ID do aplicativo atribuída ao seu aplicativo no portal do Azure. |
| segredo_do_cliente | Sim, em Aplicações Web | O segredo do aplicativo que foi gerado no portal do Azure. Os segredos do cliente são usados nesse fluxo para cenários de aplicativo Web, onde o cliente pode armazenar com segurança um segredo do cliente. Para cenários de aplicativo nativo (cliente público), os segredos do cliente não podem ser armazenados com segurança e, portanto, não são usados nesta chamada. Se você usar um segredo do cliente, altere-o periodicamente. |
| tipo de concessão | Obrigatório | O tipo de subvenção. Para o fluxo do código de autorização, o tipo de concessão deve ser authorization_code. |
| Alcance | Recomendado | Uma lista de escopos separados por espaço. Um único valor de escopo indica ao Azure AD B2C ambas as permissões que estão sendo solicitadas. 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 pela mesma ID do cliente. O offline_access escopo indica que a sua aplicação precisa de um token de renovação para acesso prolongado aos recursos. Você também pode usar o openid escopo para solicitar um token de ID do Azure AD B2C. |
| código | Obrigatório | O código de autorização que você adquiriu do /authorize ponto de extremidade. |
| uri_de_redirecionamento | Obrigatório | O URI de redirecionamento do aplicativo onde você recebeu o código de autorização. |
| verificador_de_código | recomendado | O mesmo code_verifier utilizado para obter o código de autorização. 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. |
Se você estiver testando essa solicitação HTTP POST, poderá usar qualquer cliente HTTP, como o Microsoft PowerShell.
Uma resposta de token bem-sucedida tem esta aparência:
{
"not_before": "1442340812",
"token_type": "Bearer",
"access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
"scope": "00001111-aaaa-2222-bbbb-3333cccc4444 offline_access",
"expires_in": "3600",
"refresh_token": "AAQfQmvuDy8WtUv-sd0TBwWVQs1rC-Lfxa_NDkLqpg50Cxp5Dxj0VPF1mx2Z...",
}
| Parâmetro | Descrição |
|---|---|
| não_antes | O momento em que o token é considerado válido, em tempo de época. |
| tipo_de_token | O valor do tipo de 'token'. O único tipo que o Microsoft Entra ID suporta é *Bearer*. |
| token de acesso | O JSON Web Token (JWT) assinado que você solicitou. |
| Alcance | Os escopos para os quais o token é válido. Você também pode usar escopos para armazenar tokens em cache para uso posterior. |
| expira em | O período de tempo em que o token é válido (em segundos). |
| token de atualização | Um token de atualização OAuth 2.0. O aplicativo pode usar esse token para adquirir tokens adicionais depois que o token atual expirar. Os tokens de atualização são duradouros. Você pode usá-los para manter o acesso aos recursos por longos períodos de tempo. Para obter mais informações, consulte a referência de token do Azure AD B2C. |
As respostas de erro têm esta aparência:
{
"error": "access_denied",
"error_description": "The user revoked access to the app.",
}
| Parâmetro | Descrição |
|---|---|
| erro | Uma cadeia de caracteres de código de erro que você pode usar para classificar os tipos de erros que ocorrem. Você também pode usar a cadeia de caracteres para reagir a erros. |
| descrição_do_erro | Uma mensagem de erro específica que pode ajudá-lo a identificar a causa raiz de um erro de autenticação. |
3. Use o token
Agora que você adquiriu com êxito um token de acesso, pode usá-lo em solicitações para suas APIs da Web de back-end incluindo-o Authorization no cabeçalho:
GET /tasks
Host: mytaskwebapi.com
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...
4. Atualize o token
Os tokens de acesso e os tokens de ID têm vida curta. Depois que eles expirarem, você deve atualizá-los para continuar a acessar recursos. Quando você atualiza o token de acesso, o Azure AD B2C retorna um novo token. O token de acesso atualizado terá os valores de reivindicação atualizados: nbf (não antes de), iat (emitido em) e exp (expiração). Todos os outros valores de declaração são os mesmos que o token de acesso emitido originalmente.
Para atualizar o token, envie outro pedido POST para o endpoint /token. Desta vez, forneça o refresh_token em vez do code:
POST https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/token HTTP/1.1
Content-Type: application/x-www-form-urlencoded
grant_type=refresh_token
&client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&scope=00001111-aaaa-2222-bbbb-3333cccc4444 offline_access
&refresh_token=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&redirect_uri=urn:ietf:wg:oauth:2.0:oob
| Parâmetro | Necessário? | Descrição |
|---|---|---|
| {inquilino} | Obrigatório | Nome do inquilino do Azure AD B2C |
| {política} | Obrigatório | O fluxo de usuário que foi usado para adquirir o token de atualização original. Não é possível usar um fluxo de usuário diferente nessa solicitação. |
| ID do cliente | Obrigatório | A ID do aplicativo atribuída ao seu aplicativo no portal do Azure. |
| segredo_do_cliente | Sim, em Aplicações Web | O segredo do aplicativo que foi gerado no portal do Azure. Os segredos do cliente são usados nesse fluxo para cenários de aplicativo Web, onde o cliente pode armazenar com segurança um segredo do cliente. Para cenários de aplicativo nativo (cliente público), os segredos do cliente não podem ser armazenados com segurança e, portanto, não são usados nesta chamada. Se você usa um segredo do cliente, altere-o periodicamente. |
| tipo de concessão | Obrigatório | O tipo de subvenção. Para esta etapa do fluxo do código de autorização, o tipo de concessão deve ser refresh_token. |
| Alcance | Recomendado | Uma lista de escopos separados por espaço. Um único valor de escopo indica ao Microsoft Entra ID ambas as permissões que estão sendo solicitadas. 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 pela mesma ID do cliente. O offline_access escopo indica que a sua aplicação precisa de um token de renovação para acesso prolongado aos recursos. Você também pode usar o openid escopo para solicitar um token de ID do Azure AD B2C. |
| uri_de_redirecionamento | Opcional | O URI de redirecionamento do aplicativo onde você recebeu o código de autorização. |
| token de atualização | Obrigatório | O token de atualização original que adquiriste na segunda fase do fluxo. |
Uma resposta de token bem-sucedida tem esta aparência:
{
"not_before": "1442340812",
"token_type": "Bearer",
"access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
"scope": "00001111-aaaa-2222-bbbb-3333cccc4444 offline_access",
"expires_in": "3600",
"refresh_token": "AAQfQmvuDy8WtUv-sd0TBwWVQs1rC-Lfxa_NDkLqpg50Cxp5Dxj0VPF1mx2Z...",
}
| Parâmetro | Descrição |
|---|---|
| não_antes | O momento em que o token é considerado válido, em tempo de época. |
| tipo_de_token | O valor do tipo de 'token'. O único tipo que o Microsoft Entra ID suporta é *Bearer*. |
| token de acesso | O JWT assinado que você solicitou. |
| Alcance | Os escopos para os quais o token é válido. Você também pode usar os escopos para armazenar tokens em cache para uso posterior. |
| expira em | O período de tempo em que o token é válido (em segundos). |
| token de atualização | Um token de atualização OAuth 2.0. O aplicativo pode usar esse token para adquirir tokens adicionais depois que o token atual expirar. Os tokens de atualização são de longa duração e podem ser usados para manter o acesso aos recursos por longos períodos de tempo. Para obter mais informações, consulte a referência de token do Azure AD B2C. |
As respostas de erro têm esta aparência:
{
"error": "access_denied",
"error_description": "The user revoked access to the app.",
}
| Parâmetro | Descrição |
|---|---|
| erro | Uma cadeia de caracteres de código de erro que você pode usar para classificar tipos de erros que ocorrem. Você também pode usar a cadeia de caracteres para reagir a erros. |
| descrição_do_erro | Uma mensagem de erro específica que pode ajudá-lo a identificar a causa raiz de um erro de autenticação. |
Usar seu próprio diretório do Azure AD B2C
Para experimentar essas solicitações por conta própria, conclua as etapas a seguir. Substitua os valores de exemplo que usamos neste artigo pelos seus próprios valores.
- Crie um diretório do Azure AD B2C. Use o nome do seu diretório nas solicitações.
- Crie um aplicativo para obter uma ID de aplicativo e um URI de redirecionamento. Inclua um cliente nativo em seu aplicativo.
- Crie seus fluxos de usuário para obter seus nomes de fluxo de usuário.