Fundamentos de autenticação e autorização no back-end

Autenticação (authn) vs autorização (authz): diferença que muda o design da API

Autenticação (authentication / authn) é o processo de provar quem você é. Em uma API, isso significa vincular uma requisição a uma identidade (um usuário, um serviço, um dispositivo) com algum mecanismo verificável.

Autorização (authorization / authz) é o processo de verificar o que você pode fazer. Em uma API, isso significa decidir se aquela identidade autenticada tem permissão para executar uma ação (ler, criar, atualizar, deletar) em um recurso específico.

Exemplo rápido em uma API REST

• Authn: validar e-mail/senha no POST /login e emitir um token/sessão.
• Authz: no GET /orders/123, permitir apenas se o usuário for dono do pedido ou tiver permissão de suporte/admin.

Conceitos-base (o vocabulário que aparece em qualquer implementação)

Identidade

Representação de “quem” está por trás da requisição. Pode ser um usuário humano (userId), um serviço (serviceId), um dispositivo (deviceId) ou uma conta técnica.

Credenciais

Provas usadas para autenticar a identidade. Exemplos: senha, chave de API, certificado, OTP, assinatura com chave privada. Credenciais não são permissões; elas só ajudam a provar identidade.

Principal / Subject

Principal é o “ator” autenticado no contexto da aplicação (muito usado em frameworks). Subject é o identificador do sujeito autenticado, comum em tokens (por exemplo, o claim sub em JWT). Na prática, ambos apontam para a identidade que será usada nas decisões de autorização.

Continue em nosso aplicativo e ...

• Ouça o áudio com a tela desligada
• Ganhe Certificado após a conclusão
• + de 5000 cursos para você explorar!

ou continue lendo abaixo...

Baixar o aplicativo

Sessão

Estado mantido (normalmente no servidor) que representa um login ativo. A API associa um identificador de sessão (frequentemente via cookie) a dados como userId, data de expiração e metadados (IP, user-agent, etc.).

Token

Artefato que o cliente envia para provar que já se autenticou. Pode ser opaco (um identificador que o servidor consulta) ou auto-contido (carrega dados assinados, como JWT). Token não é sinônimo de autorização: ele pode carregar informações úteis para autorizar, mas a decisão ainda é uma regra do servidor.

Claims

Atributos sobre o subject/principal. Exemplos: sub (id), email, role, tenantId, iat (emitido em), exp (expira em). Claims podem ser usados para decisões de autorização, mas devem ser confiáveis (assinados/verificados) e coerentes com as regras do sistema.

Escopos (scopes)

Conjunto de capacidades geralmente expresso como strings (ex.: orders:read, orders:write). Escopos são comuns em integrações e APIs com delegação de acesso. Eles descrevem “o que este token permite” em termos de API.

Permissões

Regras efetivas do sistema para permitir/neg ar ações. Podem ser modeladas como permissões finas (ex.: ORDER_READ) ou papéis/roles (ex.: ADMIN) que agregam permissões. Permissão pode depender do recurso (ex.: “pode ler pedidos que são seus”).

Como authn e authz aparecem em endpoints REST

Fluxo típico 1: login (autenticação)

No login, o objetivo é autenticar e então emitir um mecanismo para requisições futuras (sessão ou token).

Endpoint: POST /login

POST /login HTTP/1.1
Content-Type: application/json

{ "email": "ana@exemplo.com", "password": "senha123" }

Resposta (exemplo com token):

HTTP/1.1 200 OK
Content-Type: application/json

{ "accessToken": "<token>", "tokenType": "Bearer", "expiresIn": 3600 }

Resposta (exemplo com sessão via cookie):

HTTP/1.1 204 No Content
Set-Cookie: sessionId=abc123; HttpOnly; Secure; SameSite=Lax

Passo a passo prático (login)

• 1) Receber credenciais no POST /login.
• 2) Validar formato (ex.: e-mail válido, senha não vazia).
• 3) Verificar credenciais (ex.: comparar hash da senha armazenada).
• 4) Se válido, criar sessão no servidor ou emitir token assinado.
• 5) Retornar token no corpo (Bearer) ou cookie de sessão.

Fluxo típico 2: acesso a recurso protegido (autenticação + autorização)

Ao acessar um recurso protegido, a API precisa primeiro identificar o principal (authn) e depois decidir se ele pode executar a ação (authz).

Endpoint: GET /orders/123

Requisição com Bearer token:

GET /orders/123 HTTP/1.1
Authorization: Bearer <token>

Passo a passo prático (acesso protegido)

• 1) Extrair credencial de requisição (ex.: header Authorization ou cookie de sessão).
• 2) Autenticar: validar token (assinatura/expiração) ou consultar sessão no servidor.
• 3) Construir o principal no contexto (ex.: principal.userId, principal.scopes).
• 4) Autorizar: checar permissões para a ação e o recurso (ex.: “pode ler este pedido?”).
• 5) Se autorizado, retornar o recurso; se não, responder com erro apropriado.

Códigos HTTP comuns e o que significam

Exemplo prático de regra de autorização (dono do recurso)

Suponha que apenas o dono do pedido ou um admin pode ver /orders/:id.

// Pseudocódigo
principal = authenticate(request) // authn
order = ordersRepo.findById(id)

if (principal.role == "ADMIN") return order
if (order.userId == principal.userId) return order

return 403

Exemplo prático de regra de autorização (escopos)

Suponha que integrações usem escopos no token.

// Pseudocódigo
principal = authenticate(request)

if (!principal.scopes.includes("orders:read")) return 403
return ordersRepo.list()

Fluxo típico 3: logout (encerrar sessão/revogar acesso)

Logout significa “encerrar a forma de autenticação contínua”. Em sessão, normalmente invalida a sessão no servidor. Em token auto-contido, logout pode ser “apagar no cliente” (remover token) e/ou revogar via lista/versão/blacklist dependendo do desenho.

Endpoint: POST /logout

POST /logout HTTP/1.1
Cookie: sessionId=abc123

Passo a passo prático (logout com sessão)

• 1) Identificar a sessão pelo cookie.
• 2) Invalidar/remover a sessão no armazenamento do servidor.
• 3) Retornar cookie expirado para o cliente.

HTTP/1.1 204 No Content
Set-Cookie: sessionId=; Expires=Thu, 01 Jan 1970 00:00:00 GMT; HttpOnly; Secure; SameSite=Lax

Separando responsabilidades: onde termina authn e começa authz

Authn responde: “quem é você?”

• Validar credenciais (senha, token, sessão).
• Extrair/confirmar identidade (ex.: sub).
• Montar o principal no contexto da requisição.

Authz responde: “você pode fazer isso aqui, agora?”

• Checar permissões/roles/escopos.
• Aplicar regras por recurso (ownership, tenant, status do objeto).
• Aplicar políticas (ex.: horário, região, risco, MFA exigido).

Mini-glossário (consulta rápida)

• Authn (autenticação): processo de provar identidade.
• Authz (autorização): processo de verificar permissões para uma ação.
• Identidade: entidade representada (usuário/serviço/dispositivo).
• Credencial: prova usada para autenticar (senha, token, certificado).
• Sessão: estado de login armazenado no servidor e referenciado por um id.
• Token: artefato enviado pelo cliente para se identificar após login.
• Principal: identidade autenticada no contexto da aplicação.
• Subject (sub): identificador do sujeito autenticado (comum em tokens).
• Claims: atributos sobre o subject (ex.: sub, role, exp).
• Escopos: capacidades declaradas (ex.: orders:read).
• Permissões: regras efetivas que permitem/negam ações.

Exercícios de classificação (authn vs authz) com cenários reais

Instrução: para cada cenário, marque se é principalmente Autenticação (authn), Autorização (authz) ou Ambos. Em seguida, descreva qual seria o comportamento esperado da API (status HTTP e por quê).

Cenários

1. Uma requisição para GET /me chega sem header Authorization e sem cookie de sessão.

2. O token Bearer foi enviado, mas está expirado (exp no passado).

3. Usuário autenticado tenta DELETE /users/42, mas não é admin.

4. Usuário autenticado tenta GET /orders/123, mas o pedido pertence a outro usuário.

5. Integração de parceiro chama POST /orders com token válido, porém sem o escopo orders:write.

6. Usuário informa senha errada no POST /login.

7. Usuário autenticado tenta acessar GET /reports, permitido apenas para quem tem permissão REPORTS_READ e está no tenant correto.

8. Após POST /logout, o cliente tenta reutilizar o mesmo cookie de sessão em GET /me.

Gabarito esperado (para autocorreção)

• 1) Authn (provável 401).
• 2) Authn (provável 401).
• 3) Authz (provável 403).
• 4) Authz (provável 403 ou 404 dependendo da política).
• 5) Authz (provável 403).
• 6) Authn (provável 401 ou 400 conforme contrato).
• 7) Ambos (authn para identificar; authz para tenant + permissão; provável 403 se falhar).
• 8) Authn (sessão inválida; provável 401).