Identidade e acesso

Gestão de identidade e controle de acesso em arquiteturas distribuídas: autenticação, autorização, JWT, OAuth2 e modelos como RBAC.

Por que a identidade é o primeiro pilar de segurança

Em qualquer sistema distribuído, a primeira pergunta que deve ser respondida diante de cada request é: quem é você e o que você pode fazer? Sem uma gestão sólida de identidade e acesso, as demais medidas de segurança perdem sentido.

A identidade não é apenas “login e senha”. É um sistema completo que abrange como as credenciais são verificadas, como as permissões são representadas, como as decisões de acesso se propagam entre serviços e como são revogadas quando necessário.

Autenticação vs autorização

Esses dois conceitos costumam ser confundidos, mas são responsabilidades distintas:

Autenticação (AuthN)

Responde à pergunta: quem é você?

Verifica a identidade do usuário ou serviço
Baseia-se em credenciais: senha, token, certificado, biometria
Produz um artefato de identidade (tipicamente um token)
Ocorre uma vez no início da sessão (ou ao renovar o token)

Autorização (AuthZ)

Responde à pergunta: o que você pode fazer?

Verifica as permissões do usuário autenticado
Baseia-se em papéis (roles), permissões, políticas ou atributos
É avaliada em cada operação que requer acesso
Pode ser tão simples quanto um papel ou tão complexa quanto políticas baseadas em atributos

Usuário → [Autenticação] → "Você é João, papel: editor"
João → [Autorização] → "João pode editar este recurso?" → Sim/Não

JSON Web Tokens (JWT)

JWT é o padrão mais utilizado para representar claims de identidade em arquiteturas distribuídas.

Estrutura de um JWT

Um JWT tem três partes separadas por pontos:

header.payload.signature

{
  "header": {
    "alg": "RS256",
    "typ": "JWT"
  },
  "payload": {
    "sub": "user-456",
    "email": "maria@ejemplo.com",
    "role": "admin",
    "permissions": ["read:users", "write:users", "read:orders"],
    "iat": 1705312200,
    "exp": 1705314000,
    "iss": "auth-service",
    "aud": "api-gateway"
  }
}

Claims importantes

Claim	Significado
`sub`	Subject — identificador único do usuário
`iss`	Issuer — quem emitiu o token
`aud`	Audience — para quem o token é destinado
`exp`	Expiration — quando expira
`iat`	Issued At — quando foi emitido
`role`	Papel do usuário (claim personalizado)
`permissions`	Permissões específicas (claim personalizado)

Vantagens do JWT em microsserviços

Stateless: cada serviço pode verificar o token sem consultar um banco de dados central
Propagação: o token viaja no header Authorization entre serviços
Autocontido: inclui todas as informações necessárias para tomar decisões de acesso

Riscos e mitigações

Token roubado: usar tempos de expiração curtos (15–30 minutos)
Claims desatualizados: o token pode conter permissões que já foram revogadas; usar refresh tokens e listas de revogação
Tamanho excessivo: não incluir dados desnecessários no payload

OAuth 2.0

OAuth 2.0 é um framework de autorização que permite que aplicações de terceiros acessem recursos em nome de um usuário, sem expor suas credenciais.

Fluxos principais

Authorization Code (com PKCE)

O fluxo mais seguro, recomendado para aplicações web e mobile:

sequenceDiagram
    participant U as Usuario
    participant App as Aplicación
    participant AS as Authorization Server
    participant API as Resource Server

    U->>App: Clic en "Iniciar sesión"
    App->>AS: Redirect a /authorize (+ code_challenge)
    AS->>U: Muestra pantalla de login
    U->>AS: Ingresa credenciales
    AS->>App: Redirect con authorization code
    App->>AS: POST /token (code + code_verifier)
    AS-->>App: Access token + refresh token
    App->>API: Request con access token
    API-->>App: Datos protegidos

Client Credentials

Para comunicação serviço-a-serviço, sem usuário envolvido:

Serviço A → POST /token (client_id + client_secret) → Access token
Serviço A → Request ao Serviço B com access token

Quando usar OAuth 2.0

Integração com provedores de identidade externos (Google, GitHub, Azure AD)
Aplicações que precisam acessar APIs em nome do usuário
Cenários em que é necessário consentimento explícito do usuário

Modelos de controle de acesso

RBAC — Role-Based Access Control

O modelo mais comum. As permissões são atribuídas a papéis (roles), e os papéis são atribuídos a usuários.

Usuário → Papel → Permissões

Exemplo:
  Maria → admin  → [criar_usuario, excluir_usuario, ver_relatorios]
  João  → editor → [editar_conteudo, ver_relatorios]
  Ana   → viewer → [ver_relatorios]

Vantagens: simples de entender, fácil de auditar, suficiente para a maioria das aplicações.

Limitações: não lida bem com permissões condicionais (“pode editar apenas seus próprios recursos”).

ABAC — Attribute-Based Access Control

As permissões são avaliadas em função de atributos do usuário, do recurso e do contexto:

Política: "Um usuário pode editar um documento SE:
  - usuario.departamento == documento.departamento
  - E documento.estado != 'publicado'
  - E hora_atual está dentro do horário de trabalho"

Vantagens: extremamente flexível, lida com casos complexos.

Limitações: mais difícil de implementar, auditar e depurar.

Recomendação prática

Comece com RBAC. Migre para ABAC somente se tiver requisitos de acesso condicional que o RBAC não consiga resolver. Muitos sistemas combinam os dois: RBAC para a estrutura base e regras ABAC para casos específicos.

Propagação de identidade entre serviços

Em uma arquitetura de microsserviços, a identidade deve se propagar de serviço em serviço:

Frontend → API Gateway → BFF → Serviço A → Serviço B
           [verifica]   [propaga JWT]  [propaga JWT]

Estratégias de propagação

Token passthrough: o mesmo JWT do usuário é repassado entre os serviços. Simples, mas o token pode ter mais permissões do que o necessário.
Token exchange: cada serviço solicita um novo token com escopo reduzido para o serviço seguinte. Mais seguro, porém mais complexo.
Service mesh com mTLS: a identidade do serviço é verificada em nível de rede, e a identidade do usuário viaja no JWT. Combina as duas camadas.

Boas práticas

Centralize a autenticação em um serviço dedicado (Auth Service ou Identity Provider)
Use tokens de curta duração com refresh tokens
Não armazene tokens no localStorage — use cookies httpOnly ou memória
Implemente revogação de tokens para casos de comprometimento
Registre todos os eventos de autenticação para auditoria
Use HTTPS sempre — nunca transmita credenciais em texto plano
Aplique o princípio do menor privilégio: cada serviço e usuário deve ter apenas as permissões de que necessita

Resumo

A gestão de identidade e acesso é a base sobre a qual se constrói toda a segurança do sistema. O JWT fornece um mecanismo stateless para propagar identidade entre serviços, o OAuth 2.0 padroniza os fluxos de autorização, e modelos como RBAC e ABAC definem como as decisões de acesso são tomadas. A chave é projetar esses mecanismos desde o início, e não adicioná-los como um remendo posterior.