Iniciar sessão na Web com OpenID Connect no Azure Ative Directory B2C

O OpenID Connect é um protocolo de autenticação, construído sobre o OAuth 2.0, que pode ser usado para conectar usuários com segurança a aplicativos da Web. Usando a implementação do Azure Ative Directory B2C (Azure AD B2C) do OpenID Connect, você pode terceirizar a inscrição, o logon e outras experiências de gerenciamento de identidade em seus aplicativos Web para o Microsoft Entra ID. Este guia mostra-lhe como fazê-lo de uma forma independente da língua. Ele descreve como enviar e receber mensagens HTTP sem usar nenhuma de nossas bibliotecas de código aberto.

O OpenID Connect estende o protocolo de autorização OAuth 2.0 para uso como um protocolo de autenticação . Esse protocolo de autenticação permite que você execute o logon único. Ele introduz o conceito de um token de ID, que permite ao cliente verificar a identidade do usuário e obter informações básicas de perfil sobre o usuário.

O OpenID Connect também permite que os aplicativos adquiram tokens de acesso com segurança. Você pode usar tokens de acesso para acessar recursos que o servidor de autorização protege. Recomendamos o OpenID Connect se você estiver criando um aplicativo da Web que hospeda em um servidor e acessado por meio de um navegador. Para obter mais informações sobre tokens, consulte Visão geral de tokens no Azure Ative Directory B2C

O Azure AD B2C estende o protocolo padrão OpenID Connect para fazer mais do que simples autenticação e autorização. Ele introduz o parâmetro de fluxo de usuário, que permite que você use o OpenID Connect para adicionar experiências de usuário ao seu aplicativo, como inscrição, login e gerenciamento de perfil.

Enviar pedidos de autenticação

Quando seu aplicativo Web precisa autenticar o usuário e executar um fluxo de usuário, ele pode direcionar o usuário para o /authorize ponto de extremidade. O usuário executa uma ação dependendo do fluxo do usuário.

Nessa solicitação, o cliente indica as permissões que precisa adquirir do usuário no scope parâmetro e especifica o fluxo de usuário a ser executado. Para ter uma ideia de como a solicitação funciona, cole-a em seu navegador e execute-a. Substituir:

• {tenant} com o nome do seu inquilino.
• 00001111-aaaa-2222-bbbb-3333cccc4444 com o ID de uma aplicação que registou no seu locatário.
• {application-id-uri}/{scope-name} com o URI da ID do Aplicativo e o escopo de um aplicativo que você registrou em seu locatário.
• {policy} com o nome da política que você tem em seu locatário, por exemplo b2c_1_sign_in.

GET /{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/authorize?
Host: {tenant}.b2clogin.com

client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&response_type=code+id_token
&redirect_uri=https%3A%2F%2Fjwt.ms%2F
&response_mode=fragment
&scope=openid%20offline_access%20{application-id-uri}/{scope-name}
&state=arbitrary_data_you_can_receive_in_the_response
&nonce=12345

Neste ponto, o usuário é solicitado a concluir o fluxo de trabalho. O usuário pode ter que digitar seu nome de usuário e senha, entrar com uma identidade social ou se inscrever no diretório. Pode haver qualquer outro número de etapas, dependendo de como o fluxo do usuário é definido.

Depois que o usuário conclui o fluxo de usuário, uma resposta é retornada ao seu aplicativo no parâmetro indicado redirect_uri , usando o método especificado no response_mode parâmetro. A resposta é a mesma para cada um dos casos anteriores, independentemente do fluxo de usuários.

Uma resposta bem-sucedida usando response_mode=fragment seria semelhante a:

GET https://jwt.ms/#
id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...
&code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&state=arbitrary_data_you_can_receive_in_the_response

As respostas de erro também podem ser enviadas para o redirect_uri parâmetro para que o aplicativo possa manipulá-las adequadamente:

GET https://jwt.ms/#
error=access_denied
&error_description=AADB2C90091%3a+The+user+has+cancelled+entering+self-asserted+information.%0d%0aCorrelation+ID%3a+xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx%0d%0aTimestamp%3a+xxxx-xx-xx+xx%3a23%3a27Z%0d%0a
&state=arbitrary_data_you_can_receive_in_the_response

Validar o token de identidade

Apenas receber um token de ID não é suficiente para autenticar o usuário. Valide a assinatura do token de ID e verifique as declarações no token de acordo com os requisitos do seu aplicativo. O Azure AD B2C usa JSON Web Tokens (JWTs) e criptografia de chave pública para assinar tokens e verificar se eles são válidos.

O Azure AD B2C possui um ponto de extremidade de metadados do OpenID Connect, permitindo a um aplicativo obter informações sobre o Azure AD B2C em tempo de execução. Essas informações incluem pontos de extremidade, conteúdos de tokens e chaves de assinatura de token. Há um documento de metadados JSON para cada fluxo de usuário em seu locatário B2C. Por exemplo, o documento de metadados para o b2c_1_sign_in fluxo de usuário está localizado em fabrikamb2c.onmicrosoft.com :

https://fabrikamb2c.b2clogin.com/fabrikamb2c.onmicrosoft.com/b2c_1_sign_in/v2.0/.well-known/openid-configuration

Uma das propriedades deste documento de configuração é jwks_uri, cujo valor para o mesmo fluxo de usuário seria:

https://fabrikamb2c.b2clogin.com/fabrikamb2c.onmicrosoft.com/b2c_1_sign_in/discovery/v2.0/keys

Para determinar qual fluxo de usuário foi usado para assinar um token de ID, você tem duas opções. Primeiro, o nome do fluxo de usuário é incluído no "claim" acr no token de ID, consulte claim que representa o fluxo do usuário. A outra opção é codificar o fluxo de utilizador no valor do parâmetro state ao emitir a solicitação e, em seguida, decodificá-lo para determinar qual fluxo de utilizador foi usado. Qualquer um dos métodos é válido.

Depois de adquirires o documento de metadados do endpoint de metadados OpenID Connect, podes usar as chaves públicas RSA 256 para validar a assinatura do token de identificação. Pode haver várias chaves listadas neste endpoint, cada uma identificada por uma kid afirmação. O cabeçalho do token de ID também contém uma kid declaração, que indica qual dessas chaves foi usada para assinar o token de ID.

Para verificar os tokens do Azure AD B2C, você precisa gerar a chave pública usando o expoente(e) e o módulo(n). Para fazer isso, você precisa aprender a gerar a chave pública em uma linguagem de programação de sua escolha. A documentação oficial sobre a geração de Chave Pública com o protocolo RSA pode ser encontrada aqui: https://tools.ietf.org/html/rfc3447#section-3.1

Depois de validar a assinatura do token de ID, há várias declarações que você precisa verificar. Por exemplo:

• Valide a reivindicação nonce para evitar ataques de repetição de tokens. Seu valor deve ser o que você especificou na solicitação de entrada.
• Valide a aud declaração para garantir que o token de ID foi emitido para seu aplicativo. Seu valor deve ser o ID do aplicativo do seu aplicativo.
• Valide as declarações iat e exp para certificar-se de que o token de ID não expirou.

Há também várias outras validações que você deve realizar. As validações são descritas em detalhes na especificação principal do OpenID Connect. Você também pode querer validar mais declarações, dependendo do seu cenário. Algumas validações comuns incluem:

• Certifique-se de que o usuário/organização se inscreveu no aplicativo.
• Certifique-se de que o usuário tem autorização/privilégios adequados.
• Verifique se ocorreu um determinado nível de autenticação, como a autenticação multifator do Microsoft Entra.

Depois que o token de ID for validado, você poderá iniciar uma sessão com o usuário. Você pode usar as declarações no token de ID para obter informações sobre o usuário em seu aplicativo. Os usos para essas informações incluem exibição, registros e autorização.

Obter um token

Se você precisar que seu aplicativo Web execute apenas fluxos de usuário, poderá ignorar as próximas seções. Essas seções são aplicáveis somente a aplicativos Web que precisam fazer chamadas autenticadas para uma API da Web, que é protegida pelo próprio Azure AD B2C.

Você pode resgatar o código de autorização adquirido (usando response_type=code+id_token) para obter um token para o recurso desejado enviando um pedido 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 back-end do seu aplicativo. Nesse caso, você usa o ID do cliente do aplicativo como o escopo solicitado, o que resulta em um token de acesso com esse ID do cliente como "público-alvo":

POST https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/token HTTP/1.1
Host: {tenant}.b2clogin.com
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

Uma resposta de token bem-sucedida tem o seguinte formato:

{
    "not_before": "1442340812",
    "token_type": "Bearer",
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
    "scope": "00001111-aaaa-2222-bbbb-3333cccc4444 offline_access",
    "expires_in": "3600",
    "expires_on": "1644254945",
    "refresh_token": "AAQfQmvuDy8WtUv-sd0TBwWVQs1rC-Lfxa_NDkLqpg50Cxp5Dxj0VPF1mx2Z...",
}

As respostas de erro são parecidas:

{
    "error": "invalid_grant",
    "error_description": "AADB2C90080: The provided grant has expired. Please re-authenticate and try again. Current time: xxxxxxxxxx, Grant issued time: xxxxxxxxxx, Grant expiration time: xxxxxxxxxx\r\nCorrelation ID: xxxxxxxx-xxxx-xxxX-xxxx-xxxxxxxxxxxx\r\nTimestamp: xxxx-xx-16 xx:10:52Z\r\n"
}

Utilize o token

Depois de adquirir com êxito um token de acesso, poderá usá-lo em pedidos para as suas APIs web de back-end, incluindo-o no cabeçalho Authorization.

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

Atualizar 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á valores de declaração atualizados nbf (não antes), iat (emitidos em) e exp (expiração). Todos os outros valores de declaração são semelhantes aos do token de acesso anterior.

Atualize um token enviando outro POST pedido para o /token endpoint. Desta vez, forneça o refresh_token parâmetro em vez do code parâmetro:

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

grant_type=refresh_token
&client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&scope=openid offline_access
&refresh_token=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&redirect_uri=urn:ietf:wg:oauth:2.0:oob

Uma resposta de token bem-sucedida tem o seguinte formato:

{
    "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...",
    "refresh_token_expires_in": "1209600"
}

As respostas de erro são parecidas:

{
    "error": "invalid_grant",
    "error_description": "AADB2C90129: The provided grant has been revoked. Please reauthenticate and try again.\r\nCorrelation ID: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx\r\nTimestamp: xxxx-xx-xx xx:xx:xxZ\r\n",
}

Enviar uma solicitação de saída

Quando você deseja desconectar o usuário do aplicativo, não é suficiente limpar os cookies do aplicativo ou encerrar a sessão com o usuário. Redirecionar o usuário para o Azure AD B2C para sair. Se você não conseguir fazer isso, o usuário poderá se autenticar novamente em seu aplicativo sem inserir suas credenciais novamente. Para obter mais informações, consulte Comportamento de sessão do Azure AD B2C.

Para encerrar a sessão do utilizador, redirecione o utilizador para o end_session_endpoint que está listado no documento de metadados do OpenID Connect descrito anteriormente:

GET https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/logout?post_logout_redirect_uri=https%3A%2F%2Fjwt.ms%2F

Após uma solicitação de saída, o Azure AD B2C invalida a sessão baseada em cookies do Azure AD B2C e tenta sair de provedores de identidade federados. Para obter mais informações, consulte Encerramento de sessão única.

Proteja o redirecionamento de logout

Após o logout, o usuário é redirecionado para o URI especificado no post_logout_redirect_uri parâmetro, independentemente das URLs de resposta especificadas para o aplicativo. No entanto, se um id_token_hint válido for passado e o Exigir Token de ID em solicitações de logout estiver ativado, o Azure AD B2C verificará se o valor de post_logout_redirect_uri corresponde a um dos URIs de redirecionamento configurados do aplicativo, antes de executar o redirecionamento. Se nenhuma URL de resposta correspondente tiver sido configurada para o aplicativo, uma mensagem de erro será exibida e o usuário não será redirecionado.

Para definir o Token de ID necessário em solicitações de logout, consulte Configurar o comportamento da sessão no Azure Ative Directory B2C.

Conteúdo relacionado

• Saiba mais sobre a sessão B2C do Azure AD.