Segurança: OAuth 2.0, OIDC e Zero Trust

No Hands-on 3 protegemos a loja com um esquema caseiro: o auth-service verifica a senha, assina um JSON Web Token (JWT) com um segredo HMAC e o devolve em um cookie; a cada requisição, o gateway pede ao auth-service que resolva o token e repassa o id de quem chamou no header id-account. Isso funciona para uma aplicação web com um formulário de login. Agora a loja quer "Entrar com Google", um aplicativo móvel, um job noturno que chama o order-service sem nenhum usuário por trás e — um dia — uma biblioteca vulnerável permite que um atacante execute código dentro do pod do product-service. O esquema caseiro não tem resposta para nenhum desses casos.

O JWT é um formato de transporte — ele carrega claims como "esta é a conta 42". Ele não diz nada sobre como o usuário provou sua identidade, quem pode emitir tokens, como um aplicativo de terceiros obtém acesso sem ver a senha, ou por que um serviço deveria confiar em uma chamada vinda de outro. OAuth 2.0 e OpenID Connect são os padrões que preenchem essas lacunas; Zero Trust é a arquitetura que deixa de confiar na própria rede: desconfie de tudo, verifique sempre.

Slides

Clique nos slides e use ← → para navegar; F abre em tela cheia e P abre a visão do apresentador, com as notas. Abrir os slides em uma nova aba

Roteiro

1. Visão geral (esta página) — autenticação vs. autorização, o que o Hands-on 3 construiu, o que o JWT sozinho não resolve e o mapa das camadas de segurança da loja.
2. OAuth 2.0 e OpenID Connect — papéis, tokens e escopos, tipos de grant (Authorization Code + PKCE, Client Credentials), OIDC e o ID Token, e como o gateway valida tokens (JWKS vs. introspecção).
3. Zero Trust, mTLS e segredos — perímetro vs. Zero Trust, TLS mútuo e identidade de workload, NetworkPolicy do Kubernetes e gestão de segredos.

Autenticação vs. autorização

Duas perguntas são feitas a cada requisição, e elas costumam ser confundidas:

Alguns termos usados ao longo da aula:

• Principal — a entidade autenticada: um usuário (ada@store.com) ou um workload (order-service).
• Credencial — o que um principal apresenta para provar sua identidade (uma senha, uma chave privada, um token).
• Token — uma string emitida após a autenticação, que o principal apresenta no lugar da credencial. Um bearer token dá acesso a quem o possuir, como dinheiro vivo: roube-o e você pode gastá-lo.
• Claim — uma afirmação dentro de um token, como "sub": "42" ou "scope": "orders:read".

O que o Hands-on 3 construiu

O fluxo abaixo é o que você implementou: o token é uma referência que só o auth-service consegue ler, e o gateway pergunta por ela a cada chamada.

sequenceDiagram
    autonumber
    actor B as Navegador
    participant GW as gateway-service
    participant AU as auth-service
    participant AC as account-service
    B->>GW: POST /auth/login {email, password}
    GW->>AU: encaminha (rota aberta)
    AU->>AU: verifica a senha, assina o JWT (segredo HMAC)
    AU-->>B: Set-Cookie: __store_jwt_token
    B->>GW: GET /accounts/me + cookie
    GW->>AU: POST /auth/solve {token}
    AU-->>GW: {idAccount}
    GW->>AC: GET /accounts/me + header id-account
    AC-->>B: 200 OK

É um design sólido para uma única aplicação, e ele tem três propriedades que vale nomear:

• Assinatura simétrica (HMAC, por exemplo HS256) — o mesmo segredo assina e verifica. Só o auth-service guarda a JWT_SECRET_KEY, então só ele pode validar tokens; é por isso que o gateway precisa chamá-lo.
• Validação remota — um salto de rede extra por requisição, mas o auth-service pode recusar um token imediatamente (por exemplo, após o logout).
• Confiança na rede — o account-service acredita em qualquer header id-account, porque só o gateway consegue alcançá-lo dentro da rede Docker.

O que o JWT sozinho não resolve

As camadas de segurança da loja

Nenhum controle isolado protege um sistema. A defesa em profundidade empilha camadas independentes, de modo que um atacante que vença uma ainda enfrente a próxima. O diagrama acompanha uma requisição desde a Internet até os dados:

flowchart LR
    U(["Cliente"]) -->|"HTTPS (TLS)"| GW["Gateway<br>valida o token"]
    IdP["Provedor de identidade<br>(auth-service / Keycloak)"] -->|"emite tokens"| U
    GW -->|"header de identidade<br>(mTLS interno)"| SVC["order-service<br>verifica a propriedade"]
    SVC -->|"permitido pela<br>NetworkPolicy"| PS["product-service"]
    SVC -->|"credencial de BD<br>de vida curta"| DB[("Postgres")]

Pontos-chave

• A autenticação responde quem, a autorização responde o quê; o gateway autentica, mas cada serviço ainda precisa autorizar o acesso aos seus próprios objetos.
• Um JWT é só um formato. O OAuth 2.0 define como os tokens são obtidos e delegados; o OIDC acrescenta uma identidade padronizada (ID Token).
• O Hands-on 3 usa uma chave simétrica e validação remota; implantações padrão usam chaves assimétricas e um JWKS, para que qualquer serviço valide localmente.
• O Zero Trust elimina a suposição de que a rede interna é segura: toda chamada carrega uma identidade verificável e é checada contra uma política.
• Segurança é feita em camadas: TLS na borda, tokens para usuários, mTLS e NetworkPolicy entre serviços, um gerenciador de segredos para as credenciais.