188 lines
3.3 KiB
Markdown
188 lines
3.3 KiB
Markdown
# Plano minimo de implementacao — comunicacao entre servicos com JWT
|
|
|
|
## Objetivo
|
|
|
|
Implementar comunicacao minima entre servicos distribuidos onde:
|
|
|
|
- o **Auth Service** autentica o usuario
|
|
- o **Auth Service** emite o **JWT**
|
|
- os outros servicos **validam o JWT localmente**
|
|
- um servico pode chamar outro **em nome do usuario**, repassando o mesmo token
|
|
- cada servico identifica o usuario autenticado pelo `sub`
|
|
|
|
---
|
|
|
|
## Arquitetura minima
|
|
|
|
### Auth Service
|
|
Responsavel por:
|
|
|
|
- login
|
|
- refresh token
|
|
- emissao do JWT
|
|
- distribuicao da chave publica para validacao nos demais servicos
|
|
|
|
### Outros servicos
|
|
Responsaveis por:
|
|
|
|
- receber `Authorization: Bearer <token>`
|
|
- validar JWT localmente
|
|
- extrair claims
|
|
- montar contexto do usuario autenticado
|
|
|
|
### Comunicacao entre servicos
|
|
Quando um servico chamar outro em nome do usuario:
|
|
|
|
- repassar o mesmo header `Authorization`
|
|
|
|
---
|
|
|
|
## Contrato minimo do JWT
|
|
|
|
Exemplo:
|
|
|
|
```json
|
|
{
|
|
"sub": "uuid-do-usuario",
|
|
"iss": "https://auth.seusistema.com",
|
|
"aud": "internal-apis",
|
|
"iat": 1776110000,
|
|
"exp": 1776110900
|
|
}
|
|
```
|
|
|
|
### Claims minimas
|
|
|
|
- `sub`: identificador do usuario
|
|
- `iss`: emissor
|
|
- `aud`: audiencia
|
|
- `iat`: emissao
|
|
- `exp`: expiracao
|
|
|
|
### Regra importante
|
|
|
|
O identificador confiavel do usuario deve ser sempre o **`sub`**.
|
|
|
|
Nao confiar em:
|
|
|
|
- `user_id` no body
|
|
- `x-user-id` em header customizado
|
|
- qualquer identificador separado do token
|
|
|
|
---
|
|
|
|
## Escolhas tecnicas minimas
|
|
|
|
### Algoritmo
|
|
- `RS256`
|
|
|
|
### Assinatura
|
|
- Auth assina com chave privada
|
|
- demais servicos validam com chave publica
|
|
|
|
### Tempo de vida (MVP)
|
|
- access token: 15 minutos
|
|
- refresh token: 7 dias
|
|
|
|
---
|
|
|
|
## Endpoints minimos do Auth
|
|
|
|
```http
|
|
POST /auth/login
|
|
POST /auth/refresh
|
|
```
|
|
|
|
### Login
|
|
Retorna:
|
|
|
|
```json
|
|
{
|
|
"access_token": "jwt_aqui",
|
|
"refresh_token": "refresh_aqui",
|
|
"token_type": "Bearer",
|
|
"expires_in": 900
|
|
}
|
|
```
|
|
|
|
### Refresh
|
|
Recebe refresh token e retorna novo access token + novo refresh token.
|
|
|
|
## Middleware minimo em cada servico
|
|
|
|
Passos:
|
|
|
|
1. ler `Authorization`
|
|
2. extrair bearer token
|
|
3. validar assinatura
|
|
4. validar `exp`
|
|
5. validar `iss`
|
|
6. validar `aud`
|
|
7. extrair claims
|
|
8. montar usuario autenticado no contexto da requisicao
|
|
|
|
Resultado esperado no contexto:
|
|
|
|
```json
|
|
{
|
|
"id": "uuid-do-usuario"
|
|
}
|
|
```
|
|
|
|
---
|
|
|
|
## Rotas protegidas minimas para teste
|
|
|
|
- `GET /profile/me`
|
|
- `GET /dashboard`
|
|
|
|
Cada rota deve:
|
|
|
|
- exigir token valido
|
|
- extrair `sub`
|
|
- retornar dados do usuario autenticado
|
|
|
|
---
|
|
|
|
## Ordem minima de implementacao
|
|
|
|
1. definir contrato do token
|
|
2. gerar chaves
|
|
3. implementar `login`, `refresh`
|
|
4. emitir JWT corretamente
|
|
5. implementar middleware JWT em 1 servico consumidor
|
|
6. proteger 1 rota simples
|
|
7. replicar middleware nos demais servicos
|
|
8. implementar propagacao de `Authorization` entre servicos
|
|
|
|
---
|
|
|
|
## Criterios de sucesso do MVP
|
|
|
|
1. login retorna `access_token`
|
|
2. acesso direto a rota protegida funciona
|
|
3. token invalido retorna `401`
|
|
4. token expirado retorna `401`
|
|
5. chamada A -> B preserva o mesmo `sub`
|
|
|
|
---
|
|
|
|
## Fora de escopo agora
|
|
|
|
- blacklist de tokens
|
|
- revogacao imediata global
|
|
- introspection por request
|
|
- machine-to-machine token
|
|
- gateway avancado
|
|
|
|
---
|
|
|
|
## Resumo executivo
|
|
|
|
O minimo para funcionar:
|
|
|
|
1. Auth emitir JWT assinado
|
|
2. servicos validarem localmente
|
|
3. `sub` como identificador confiavel
|
|
4. propagacao do mesmo bearer token entre servicos
|