O OpenID Connect (OIDC) é uma camada de identidade construída sobre o protocolo OAuth 2.0 que permite às aplicações autenticar usuários sem precisar gerenciar nem armazenar credenciais. O AWS Application Load Balancer (ALB) se integra aos provedores de identidade (IdPs) sociais mais comuns, a identidades corporativas e a qualquer IdP compatível com OIDC. Essa integração simplifica o processo de autenticação e reforça a segurança ao delegar o gerenciamento das sessões e dos tokens de autenticação a um provedor terceirizado confiável.
Embora o login seja transparente para o usuário final, identificar problemas pode ser desafiador quando a autenticação falha por causa dos saltos adicionais entre o usuário e a aplicação que ele está tentando acessar.
Este artigo busca dar visibilidade sobre como as transações HTTP se comportam, sob diferentes perspectivas, durante o fluxo de authorization code.
Se você quer saber como configurar a autenticação de usuário no seu ALB, recomendo a leitura da documentação oficial da AWS. A AWS também disponibiliza um site de demonstração onde você pode testar a funcionalidade de autenticação.
**Vamos detalhar o fluxo de autenticação passo a passo —**
O logging é essencial para manter a saúde, a segurança e a eficiência das aplicações na nuvem. Ele fornece os insights necessários para monitorar e diagnosticar problemas, garantindo que as aplicações rodem de forma estável e segura.
Para mergulhar fundo no fluxo de autenticação, coletei os seguintes logs:
- Arquivo HAR do navegador do usuário.
- Logs de acesso dos endpoints do IdP (Auth, Token, User-Info), do ALB e da aplicação de destino.
Antes de examinar as transações HTTP, recomendo se familiarizar com os diferentes componentes do OIDC e suas finalidades.
Pré-requisitos —
- O IdP está configurado para executar o fluxo de authorization code grant com os escopos pretendidos. Um Client ID e um client secret também já foram gerados.
- O ALB está configurado com uma listener rule que dispara a ação "authenticate" quando o caminho HTTP é
/auth*. Defina os parâmetros da requisição de autenticação, incluindo o client ID, o client secret, o endpoint de autorização, o endpoint de token e o endpoint de user info. Esses parâmetros são usados pelo ALB para se comunicar com o IdP.
Etapa 1 — O usuário envia uma requisição HTTP para a sua aplicação por trás de um ALB com autenticação habilitada.
Navegador redirecionado para o endpoint Auth do IdP.
Logs de acesso do ALB para essa mesma transação —
h2 2024–07–11T18:47:52.382721Z app/demo/25be909a3f190764 109.78.96.82:54871 - -1 -1 -1 302–359 657 "GET https://demo.aws.doit.com:443/auth.html HTTP/2.0" arn:aws:elasticloadbalancing:eu-west-1:21112316:targetgroup/TG/1a24c5faad770fb2 "Root=1–669028d8–653487fd74af592f498329f8" "authenticate"
- A ação de autenticação é disparada quando o usuário envia uma requisição HTTP GET ao ALB.
- Se nenhum cookie de sessão de autenticação estiver presente nos cabeçalhos da requisição HTTP, o ALB devolve uma resposta HTTP 302 e o usuário é redirecionado para a URL informada no cabeçalho Location (o endpoint de autorização do IdP).
- O
redirect_urié o destino para onde o navegador é redirecionado depois que o IdP concede o authorization code.
Etapa 2 — O usuário é redirecionado para o endpoint de autorização do IdP.
Requisição HTTP para o endpoint Auth.
- O usuário envia uma requisição HTTP para o endpoint de autorização do IdP.
- Em seguida, o endpoint de autorização do IdP redireciona o usuário para o endpoint de login do IdP (
/login). - O endpoint de login é responsável pela autenticação do usuário.
Etapa 3 — O usuário acessa o endpoint de login.
Requisição HTTP para o endpoint de login.
- O usuário envia uma requisição HTTP para o endpoint de login.
- A página de login é carregada com os campos de nome de usuário e senha.
Etapa 4 — O usuário se autentica.
O usuário informa nome de usuário e senha.
- O usuário insere as credenciais na página de login do IdP.
- Após autenticação bem-sucedida, o usuário é redirecionado de volta para o endpoint de autorização do IdP.
Exemplo de payload de uma requisição POST —
csrf=izvsVKMB-GxnSvAK6McnPw6uNcZVCqqWxjeU&challenge=cbcab3062ca041399178171a4078d30b&email=user%40name.com&password=complex&submit=Log+in
Etapa 5 — O usuário recebe o authorization code do IdP.
Authorization code concedido.
- O endpoint de autorização do IdP redireciona o usuário de volta para a aplicação cliente com um authorization code.
- Os valores originais do parâmetro
statesão preservados para manter uma relação 1:1 entre a requisição e o callback.
Etapa 6 — O usuário retorna ao ALB com o authorization code.
Usuário redirecionado de volta para /auth com o cookie de autenticação.
Logs de acesso do ALB para essa mesma transação —
h2 2024-07-11T18:48:27.805659Z app/demo/25be909a3f190764 109.78.96.82:54871 - -1 -1 -1 302 - 423 847 "GET https://demo.aws.doit.com:443/oauth2/idpresponse?code=ory_ac_9j6SCghDyFOexN03pTRP_GSJ5RHduhCLE-L74D2IlSs.zMsOhvXLbIrs0WQLtb43tkUnRZm0lWoI5T0IlNjnoO0&scope=openid&state=Y06EN0RLaODTpBbHGEpfK29AZJcLIpftyWwbyQN8EeiFyOtbN07H2nTXTGUa3DDYX5UgeMDsqP9psViZhPy41Y%2FVkNoJc5%2B6jb8po%2BLXQtcgxRgk9s5T0LgWt53mOEOjxL4nBVQ9Z9X1Sm%2BcZNO%2BFAIlh%2B6t99WKKj3vz1bekHiwdLWp18GUo9cp3eUkPWXbSBXprXOUHk2QlPK9xd7sG3AHyj4urRv3lc97AR4DRrVIECUMOsNP5BlYW6%2FGAg%3D%3D HTTP/2.0" "Root=1-669028fb-6e750f6c5c7fdde45853b7f6" "authenticate"
- O usuário apresenta o authorization code ao ALB.
- O ALB responde com um código HTTP 302 e redireciona o usuário de volta para a URI original:
https://demo.aws.doit.com/auth.html. - Antes de gerar a resposta, o ALB faz requisições de backchannel para os seguintes endpoints:
Endpoint Token do IdP, para trocar o código por um IdToken.
Requisição POST para o endpoint Token.
Endpoint UserInfo, para trocar o access token pelas claims do usuário.
Requisição para o endpoint UserInfo.
As claims do usuário, o access token e o refresh token são codificados em base64 e criptografados dentro do cookie AWSELBAuthSessionCookie.
Etapa 7 — O usuário requisita a URI original com o AWSELBAuthSessionCookie definido.
O usuário é autenticado pelo ALB e a requisição chega ao backend.
Logs de acesso do ALB para essa mesma transação —
h2 2024-07-11T18:48:27.824183Z app/demo/25be909a3f190764 109.78.96.82:54871 172.31.11.119:80 0.007 0.001 0.000 200 200 596 3307 "GET https://demo.aws.doit.com:443/auth.html HTTP/2.0" "arn:aws:elasticloadbalancing:eu-west-1:211125377316:targetgroup/healthyTG/1a24c5faad770fb2 "Root=1-669028fb-156c503c2fe1fcdb60e4a5ad" 2024-07-11T18:48:27.815000Z "authenticate,forward" "172.31.11.119:80" "200"
- As condições da regra do ALB para a ação "authenticate" são atendidas e o cookie de autenticação também está presente.
- O ALB valida o cookie e encaminha as informações do usuário aos targets nos cabeçalhos HTTP
X-AMZN-OIDC-*.
Cabeçalhos X-AMZN_OIDC* observados no target —
Cabeçalhos X-AMZN_OIDC*.
x-amzn-oidc-accesstoken- O access token vindo do endpoint Token.
x-amzn-oidc-identity- O campo subject (sub) vindo do endpoint UserInfo.
x-amzn-oidc-data- As claims do usuário, no formato JSON Web Token (JWT).
As claims do usuário no formato JWT incluem header, payload e assinatura, todos codificados em base64 URL. O ALB usa ES256 (ECDSA com P-256 e SHA256) para gerar a assinatura do JWT.
JWT decodificado —
O header do JWT é um objeto JSON que traz o issuer, os detalhes do signer e o key ID. O payload do JWT é um objeto JSON com as claims do usuário recebidas do endpoint UserInfo do IdP.
O target (Apache) autoriza o usuário com base nas claims e devolve uma resposta HTTP 200 OK ao usuário, passando pelo ALB.
Conclusão —
Este artigo traz um olhar aprofundado sobre como ocorrem as transações HTTP durante o fluxo de authorization code do OIDC ao usar o AWS Application Load Balancer (ALB). Detalhamos cada etapa, da requisição HTTP inicial do usuário até a autenticação e a autorização finais, destacando as principais interações HTTP e os detalhes de logging essenciais para diagnosticar e entender o processo.
Se quiser saber mais ou tiver interesse nos nossos serviços, fale com a gente. Você pode entrar em contato por aqui.