Autenticação (sessão, JWT, OAuth/OIDC)

01 · CONTEXTO

Duas perguntas: quem é e o que pode

Um sistema de autenticação responde a duas perguntas diferentes. A primeira é quem é a pessoa: o OpenID Connect permite que o cliente verifique a identidade do usuário com base na autenticação feita por um servidor de autorização. A segunda é o que uma aplicação pode fazer em nome dela: o OAuth permite que uma aplicação de terceiros obtenha acesso limitado a um serviço HTTP.

Resolvida a primeira pergunta, o sistema precisa lembrar o resultado, e o HTTP não ajuda: cada par de requisição e resposta é independente das outras interações. É aí que entram o identificador de sessão ou o token, que, segundo o OWASP, ligam as credenciais autenticadas ao tráfego do usuário e aos controles de acesso. Depois de estabelecida a sessão autenticada, esse identificador equivale temporariamente ao método de autenticação mais forte usado.

02 · SESSÃO NO SERVIDOR

Sessão: o estado fica no servidor

No modelo de sessão o navegador guarda só um identificador e o significado dele fica no servidor. O OWASP pede que o valor do identificador seja sem significado e nunca inclua informação sensível nem dados pessoais (PII). O significado e a lógica de negócio associados a ele ficam em objetos de sessão ou em um repositório de sessões no servidor.

A imprevisibilidade do identificador é requisito: o OWASP pede entropia suficiente para impedir adivinhação por força bruta e fixa o mínimo exigido em 64 bits.

1. O navegador envia as credenciais e o balanceador as encaminha ao serviço de autenticação.

2. O serviço de autenticação confere as credenciais no banco de usuários.

3. Autenticado o usuário, o serviço guarda o estado da sessão no armazenamento de sessões e devolve ao navegador só um identificador sem significado.

4. Nas chamadas seguintes o navegador reenvia o identificador, e a API de negócio o usa para consultar o armazenamento de sessões.

5. No logout, o servidor invalida a sessão no armazenamento de sessões.

O cookie de sessão leva dois atributos de proteção. O atributo Secure faz o navegador enviar o cookie apenas por HTTPS. O atributo HttpOnly impede que scripts acessem o cookie, proteção que o OWASP considera obrigatória contra o roubo do identificador por XSS.

O ciclo de vida também é controlado pelo servidor. O identificador deve ser renovado depois de qualquer mudança de nível de privilégio, e o cenário mais comum é o próprio processo de autenticação. Toda sessão deve ter timeout de inatividade e timeout absoluto, impostos no servidor, e o logout deve invalidar a sessão ao menos no servidor.

03 · TOKENS

Tokens autocontidos e JWT

Um JWT é uma forma compacta e segura para URL de representar claims trocadas entre duas partes. As claims podem ser assinadas ou protegidas por MAC e/ou cifradas.

Três claims registradas pesam no desenho. A claim iss identifica quem emitiu o JWT. A claim aud identifica os destinatários, e quem processa o token sem se identificar com um valor em aud deve rejeitá-lo. A claim exp marca o momento a partir do qual o token não pode mais ser aceito.

No OAuth, o access token costuma ser opaco para o cliente. Ele pode ser um identificador usado para recuperar a autorização ou conter a própria informação de autorização de forma verificável, e representa escopos e durações de acesso concedidos pelo dono do recurso e aplicados pelo servidor de recursos e pelo servidor de autorização.

1. O navegador envia as credenciais ao emissor, que as confere no banco de usuários.

2. O emissor devolve um JWT, cujas claims podem ser assinadas, entre elas iss, aud e exp.

3. O cliente apresenta o JWT ao gateway, que não aceita o token com exp vencido e o rejeita se aud não o inclui.

4. O serviço de negócio aplica os escopos e a duração de acesso representados pelo token.

5. Quando o access token expira, o cliente usa o refresh token para obter outro access token no emissor.

O access token pode ter vida mais curta e menos permissões do que o dono do recurso autorizou, e o refresh token é a credencial usada para obter novos access tokens.

Para encerrar o acesso de um token, o OAuth define um endpoint de revogação: ele permite ao cliente avisar o servidor de autorização que um refresh ou access token não é mais necessário, e o pedido invalida o token e, quando aplicável, outros tokens do mesmo grant de autorização.

04 · OAUTH E OIDC

Login federado com código de autorização

No fluxo de código de autorização do OpenID Connect, o cliente envia o pedido ao servidor de autorização, que autentica o usuário e o devolve ao cliente com um código. O cliente troca o código no endpoint de token, recebe um ID Token e um access token e valida o ID Token para obter o identificador do usuário.

Como o dono do recurso só se autentica no servidor de autorização, as credenciais dele nunca são compartilhadas com o cliente. O fluxo também evita expor tokens ao user agent e a outras aplicações maliciosas com acesso a ele.

1. A aplicação cliente envia o usuário e o pedido de autenticação ao servidor de autorização.

2. O servidor de autorização autentica o usuário, tendo o banco de usuários como base das credenciais.

3. O servidor devolve o usuário à aplicação com um código de autorização, e as credenciais do usuário não passam pela aplicação.

4. A aplicação troca o código no endpoint de token; clientes públicos devem usar PKCE para proteger o código.

5. A aplicação recebe um ID Token e um access token, valida o ID Token e obtém o identificador do usuário.

6. Com o access token, a aplicação chama a API protegida, que deve verificar se o token foi emitido para ela.

O que o OpenID Connect acrescenta ao OAuth é a camada de identidade: o ID Token é um token de segurança com claims sobre a autenticação do usuário por um servidor de autorização.

Clientes públicos do OAuth são suscetíveis ao ataque de interceptação do código de autorização, e devem usar PKCE contra a injeção e o uso indevido do código.

05 · ARMADILHAS E FECHAMENTO

O que evitar e como fechar a entrevista

As recomendações de segurança do OAuth dizem que o grant de senha do dono do recurso não deve ser usado e que os clientes não devem usar o implicit grant. Refresh tokens de clientes públicos devem ser restritos ao remetente ou usar rotação. A restrição de audiência limita o access token a um servidor de recursos específico, que verifica a audiência pretendida.