Fluxo de código de autorização do OAuth 2.0 no Azure Active Directory B2C

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 Web. Usando a implementação do Azure AD B2C (Azure Active Directory B2C) do OAuth 2.0, você pode adicionar tarefas de inscrição, entrada e outras de gerenciamento de identidade aos seus aplicativos móveis e da área de trabalho. Este artigo é independente de linguagem. No artigo, descreveremos como enviar e receber mensagens HTTP sem usar nenhuma biblioteca de software livre. Quando possível, recomendamos que você use as bibliotecas de autenticação da Microsoft (MSAL) compatíveis. Dê uma olhada nos aplicativos de exemplo que usam MSAL.

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. É possível usá-lo para autenticação e autorização na maioria dos tipos de aplicativos, incluindo aplicativos Web, de página única e aplicativos instalados nativamente. Você pode usar o fluxo do código de autorização OAuth 2.0 para adquirir com segurança tokens de acesso e atualizar tokens para os aplicativos, que podem ser usados para acessar recursos protegidos por um servidor de autorização. O token de atualização permite que o cliente adquirir novo acesso (e atualizar) tokens depois que o token de acesso expira, normalmente após uma hora.

Este artigo concentra-se no fluxo de código de autorização do OAuth 2.0 de clientes públicos. Um cliente público é qualquer aplicativo cliente que não é confiável para manter a integridade de uma senha secreta com segurança. Isso inclui aplicativos de página única, aplicativos móveis, aplicativos de área de trabalho e, essencialmente, qualquer aplicativo que não seja executado em um servidor.

O Azure AD B2C estende os fluxos padrão do OAuth 2.0 para fazer mais do que simples ações de autenticação e autorização. Ele apresenta o fluxo do usuário. Com os fluxos do usuário, você pode usar o OAuth 2.0 para adicionar experiências do 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, Facebook, GitHub, Google e LinkedIn.

Para experimentar as solicitações HTTP neste artigo:

1. Substitua {tenant} pelo nome de seu locatário do Azure AD B2C.
2. Substitua 90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6 pela ID do aplicativo que você registrou anteriormente em seu locatário Azure AD B2C.
3. Substitua {policy} pelo nome de uma política que você criou em seu locatário, por exemplo b2c_1_sign_in.

Configuração do URI de redirecionamento necessária para aplicativos de página única

O fluxo de código de autorização para aplicativos de página única requer umas configurações adicionais. Siga as instruções para criar seu aplicativo de página única para marcar corretamente o URI de redirecionamento como habilitado para CORS. Para atualizar um URI de redirecionamento existente para habilitar o CORS, você pode clicar no prompt migrar na seção "Web" do Registros de aplicativo do autenticação. Como alternativa, você pode abrir o Editor de manifesto Registros de aplicativo e definir o type campo para o URI de redirecionamento para spa na replyUrlsWithType seção.

O tipo de redirecionamento spa é compatível com versões anteriores com o fluxo implícito. Os aplicativos que atualmente usam o fluxo implícito para obter tokens podem mudar para o tipo de URI de redirecionamento spa sem problemas e continuar usando o fluxo implícito.

1. Obter 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 . Essa é a parte interativa do fluxo, na qual o usuário entra em ação. Nessa solicitação, o cliente indica no parâmetro scope as permissões que ele precisa adquirir do usuário. Os exemplos a seguir (com quebras de linha para facilitar a leitura) mostram como adquirir um código de autorização. Se você estiver testando essa solicitação HTTP GET, use o navegador.

GET https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/authorize?
client_id=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6
&response_type=code
&redirect_uri=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob
&response_mode=query
&scope=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6%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

Nesse ponto, o usuário é solicitado a concluir o fluxo de trabalho do fluxo de usuário. Isso pode exigir que o usuário insira seu nome de usuário e senha, entre com uma identidade social, inscreva-se no diretório ou realize outras etapas. As ações do usuário dependem de como o fluxo de usuário é definido.

Depois que o usuário completar o fluxo de usuário, a ID do Microsoft Entra retornará uma resposta ao seu aplicativo no valor usado para redirect_uri. Ele usa o método especificado no parâmetro response_mode. A resposta é exatamente a mesma para cada um dos cenários de ação do usuário, independentemente de qual fluxo de usuário 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

As respostas de erro também podem ser enviadas ao URI de redirecionamento, de modo que o aplicativo possa tratá-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

2. Obter um token de acesso

Agora que você adquiriu um código de autorização, será possível resgatar o code de um token para o recurso desejado enviando uma solicitação POST para o ponto de extremidade /token. No Azure AD B2C, você pode solicitar tokens de acesso para outras APIs como de costume, especificando seus escopos na solicitação.

Você também pode solicitar um token de acesso para a própria API Web de back-end do seu aplicativo por convenção de uso da ID do cliente do aplicativo como o escopo solicitado (o que resultará em um token de acesso com essa ID de cliente como o "público-alvo"):

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=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6
&scope=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6 offline_access
&code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&redirect_uri=urn:ietf:wg:oauth:2.0:oob
&code_verifier=ThisIsntRandomButItNeedsToBe43CharactersLong 

Se estiver testando 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:

{
    "not_before": "1442340812",
    "token_type": "Bearer",
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
    "scope": "90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6 offline_access",
    "expires_in": "3600",
    "refresh_token": "AAQfQmvuDy8WtUv-sd0TBwWVQs1rC-Lfxa_NDkLqpg50Cxp5Dxj0VPF1mx2Z...",
}

As respostas de erro tem esta aparência:

{
    "error": "access_denied",
    "error_description": "The user revoked access to the app.",
}

3. Usar o token

Agora que adquiriu um token de acesso com êxito, você poderá usá-lo em solicitações às suas APIs Web de back-end incluindo-o no cabeçalho Authorization:

GET /tasks
Host: mytaskwebapi.com
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...

4. Atualizar o token

Os tokens de acesso e os tokens de ID tem curta duração. Depois que eles expirarem, você deverá 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 declaração atualizados nbf (não antes), iat (emitido em) e exp (expiração). Todos os outros valores de declaração serão iguais ao token de acesso originalmente emitido.

Para atualizar o token, envie outra solicitação POST ao ponto de extremidade /token. Dessa 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=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6
&scope=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6 offline_access
&refresh_token=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&redirect_uri=urn:ietf:wg:oauth:2.0:oob

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

{
    "not_before": "1442340812",
    "token_type": "Bearer",
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
    "scope": "90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6 offline_access",
    "expires_in": "3600",
    "refresh_token": "AAQfQmvuDy8WtUv-sd0TBwWVQs1rC-Lfxa_NDkLqpg50Cxp5Dxj0VPF1mx2Z...",
}

As respostas de erro tem esta aparência:

{
    "error": "access_denied",
    "error_description": "The user revoked access to the app.",
}

Use seu próprio diretório do Azure AD B2C

Para testar essas solicitações, conclua as etapas a seguir. Substitua os valores de exemplo que usamos neste artigo pelos seus próprios valores.

1. Criar um diretório do Azure AD B2C. Use o nome do seu diretório nas solicitações.
2. Criar um aplicativo para obter uma ID de aplicativo e um URI de redirecionamento. Inclua um cliente nativo em seu aplicativo.
3. Criar os fluxos dos usuários para obter os nomes do fluxo de usuário.