OAuth2/OpenID Connect no núcleo

OIDC acima de OAuth2 é uma forma padrão de provar «quem é o usuário/cliente» e dar acesso curto à API. No núcleo da plataforma, torna-se uma capacidade de entrada única para clientes, operadores e serviços; privilégios mínimos; Risco mensurável; respeitar as regras regionais e de licenciamento.

1) Objetivos e princípios

Divisão «deploy vs enable»: descolando o código separadamente, incluindo bandeiras/políticas.
Tokens de curta duração + atualização segura, reduzindo os danos de fuga.
Multi Tenant/Região: Todos os artefatos são lançados 'tenant/region/licence'.
Políticas acima dos tokens: soluções são feitas por PDP (RBAC/ABAC), PEP em gateway/serviços.
Proteção de canais: TLS1. 2 +, se possível mTLS/DPoP, CORS/CSRF rigoroso.
Observação e auditoria: visibilidade por fluxo, por cliente, por região.

2) Fluxos e quando aplicá-los

Código Autorization + PKCE (SPA/Mobile/Web) - default para logins personalizados.
Device Autorization (console/TV/CLI) - quando não há navegador.
O Cliente Credentals (machine-to-machine) é uma integração de serviço sem o usuário.
Token Exchange (RFC 8693, OBO) - o serviço funciona em nome do usuário.
O CIBA/Back-channel (opcional) é uma autenticação sem redirecionamento.

• PAR - As configurações de autorização são transmitidas por um canal de servidor seguro.
• JAR - As configurações de solicitação estão assinadas/criptografadas.
• O JARM é uma resposta de autorização segura (JWT) resistente a submenis.
• RAR - Ricas solicitações de permissões de acesso (permissões detalhadas).

3) Tocos e marcas

• ID Tocen (OIDC) - quem entrou (mostrar apenas cliente/frente).
• Access Token (AT) - Direito de ação (vida curta).
• Refresh Token (RT) - Atualiza AT; armazenado apenas em um ambiente de confiança.

• AT: 5-15 min (web/mobile), 2-5 min (service-to-service).
• RT: 7–30 дней (web/mobile) с rotation + reuse detection.
• ID: ≤ 5 minutos

json
{
"iss":"https://auth. core",
"sub":"user_42",
"aud":["wallet","catalog"],
"exp":1730388600,"iat":1730388000,
"tenant":"brand_eu","region":"EE","licence":"EE-A1",
"scp":["wallet:read","bets:place"],     // scopes
"sid ": "sess _ abcd, ""amr": [" pwd,"" webauthn"] ,//login methods
"act":{"sub":"svc. catalog" }//if OBO
}

Assinatura: chaves públicas, em JWKS com 'kid' e rotação.

4) Circuito de sessões e logout

Server-side session для web (cookie `SameSite=Lax/Strict`, `HttpOnly`, `Secure`).
Back-Channel Logout + Front-Channel Logout (OIDC) - Finalização sincronizada de todos os clientes.
Step-Up MFA: Em ações sensíveis, reexaminação ('acr' aumenta).
Revocation & Introspation: desligamento imediato do RT/AT por incidente.

5) Segurança dos clientes

Web/ s: Código de Autorização + PKCE, nada de implicit; CORS/Conteúdo-Security-Policy rigoroso.
Mobile: navegador de sistema (AppAuth), verificação de integridade (App Attestation/DeviceCheck), armazenamento RT seguro.
Desktop/CLI/TV: Device Flow; armazenem RT em armazéns de segredo OS.
DPoP ou mTLS-bound tocens para vincular AT ao dispositivo/conexão.

6) Serviço-para-serviço

mTLS + Serviço JWT (aud-scoped), emite STS com KMS/HSM.
Identidades workload 'ov: SPIFFE/SPIRE.
Política de "estreito para amplo": audiências específicas e scopes em vez de ".

7) Registro de Scope e consentimento (consent)

O nome é 'recurso' - 'wallet: read', 'wallet: transfer', 'bets: place', 'kyc: status. read`.

Configure a visibilidade e sensibilidade dos cúmulos.
Consent screen é recolhido a partir de RAR/Scopes; guarde o histórico de consoantes e deixe-me fazer uma crítica.

json
{
"type":"wallet. transfer",
"actions":["create"],
"locations":["https://api. core/wallet"],
"datatypes":["payment"],
"resources":[{"wallet_id":"w_123","currency":"EUR","amount_max":1000}]
}

8) Integração autorizada (PDP/PEP)

O PEP na API Gateway valida o AT/DPoP/mTLS, enriquece o contexto (IP/ASN/region/tenant), pede o PDP.
O PDP (OPA/cedar) aplica a política RBAC/ABAC/ReBAC e devolve 'ALLOW/DENY' com explicação e TTL.
A caixa de soluções PEP (TTL 30-120 s) com deficiência por evento (mudança de papéis/regras).

9) Multi-tenante e regiões

Todos os tokens e sessões são marcados 'tenant/region/licence'; O PDP valida a conformidade com o recurso.
JWKS/chaves separadas e listas de retirada por região; A Região Cruzada é através de passarelas de confiança.
Restrições de residência de dados - introspecção/reconquista são aplicadas na região de origem.

10) Reforços de protocolo

PAR + JAR + JARM - Protege opções e respostas de autorização.
Nonce/State/PKCE é para todos os clientes públicos.
Pushed Device Autorization (em alto risco).
JWT Access Tokens com marcas mínimas + opaque opção para integrações externas por introspecção.
Práticas FAPI semelhantes: algoritmos de assinatura rigorosos, requisitos TLS/rerect _ uri/PKCE.

11) Erros e políticas de retorno

json
{ "error":"invalid_grant", "error_description":"refresh token reused", "error_code":"RT_REUSE" }

Критичные коды: `invalid_request`, `invalid_client`, `invalid_grant`, `invalid_scope`, `unauthorized_client`, `access_denied`, `temporarily_unavailable`.
Rate-limit para endpoint sensíveis ('/tocen ', '/introspect', '/revoke '), backoff exponencial.

12) Observação e auditoria

• `auth_code_success_rate`, `pkce_missing_rate`, `mfa_challenge/fail_rate`,
• `token_issuance_p95_ms`, `jwks_skew_ms`, `invalid_token_rate`, `rt_reuse_detected`,
• по API: `authz_p95_ms`, `deny_rate{reason}`, `dpop_mismatch_rate`, `mtls_fail_rate`.

Логи/трейсы: `client_id`, `grant_type`, `kid`, `acr/amr`, `tenant/region`, `decision`, `policy_version`, `aud`, `scp`, `sid`, `trace_id`.
Auditoria (inalterável): emissão de tokens, extensão de direitos, revogação de concordâncias, rotação de chaves.

13) Gerenciamento de chaves e rotação

Assinatura JWT: KMS/HSM, publicação JWKS com 'kid'.
Período dual-key: IdP assina os novos, e os verificadores aceitam o antigo + novo antes de mudar.
Rotação regular e revoke de emergência; monitoramento do consumo 'kid'.

14) Playbooks (runbooks)

1. Comprometer chave de assinatura

Revoke 'kid' imediatamente, lançar nova, força deficiência RT/sessões, relatório de auditoria.

2. Massa 'invalid _ tocen '/altura 401

Verificar o relógio de relógio que expirou AT, JWKS kesh quebrado; aumentar temporariamente a tolerance 'clock _ skew'.

3. Reutilizar RT

Bloquear sessão ('sid'), notificar o usuário, exigir step-up para novo logon, investigação.

4. Queda de IdP

Ativar o modo «read-only autorization»: mantenha AT ativo até TTL, limite novos logins, escreva a caixa introspectiva.

5. Ataque a '/tocen '

Reforçar rate-limit/bot-filtros, incluir mTLS/DPoP para clientes sensíveis, levar RT «frio» para um segmento separado.

15) Testes

Contract: OIDC discovery, JWKS, OpenID provider config.
Segurança: PKCE/nose/state são obrigatórios; kits negativos (trocas de 'redict _ uri', reuse RT).
Interoperability: clientes (web/mobile/CLI), fuso horário/local diferentes.
Chaos: falha PAR/JARM, atrasos de JWKS, rotated 'kid' no voo.
E2E: step-up MFA, OBO (token exchange), logout (front/back-channel), revoke/rotate.

16) Exemplos de configuração

yaml issuer: https://auth. core jwks:
rotation_days: 30 alg: ES256 tokens:
access_ttl: 10m refresh_ttl: 14d id_ttl: 5m policies:
require_pkce: true require_par: true require_jarm: true dpop_enabled: true mfa_step_up:
actions: ["wallet:transfer","payout:initiate"]
tenancy:
include_claims: ["tenant","region","licence"]
jwks_per_region: true

yaml scopes:
wallet: read: {desc: "Reading balance"}
wallet: transfer: {desc: "Transfer of funds," sensitive: true, step_up: true}
bets: place: {desc: "Betting"}
kyc:status. read: {desc: "KYC status"}
roles:
player: { allow: [bets:place] }
support: { allow: [wallet:read, kyc:status. read] }
finance: { allow: [wallet:read, wallet:transfer] }

17) Folha de cheque antes de vender

• PKCE/nose/state incluídos; PAR/JAR/JARM estão ativos.
• AT/RT/ID TTL definidos; RT rotation + reuse detation incluídos.
• DPoP ou mTLS-binding para clientes/operações sensíveis.
• JWKS c `kid`; rotação automática e monitoramento do consumo de chaves.
• Consent/RAR e registro de escopos; step-up MFA para ações sensíveis.
• PDP/PEP estão integrados, e o dinheiro de soluções com deficiência.
• Os tokens contêm 'tenant/region/licence'; respeita-se a residency.
• Observabilidade: métricas, logs, traçado; alertas em 'invalid _ tocen', 'rt _ reuse', 'jwks _ skew'.
• Playbooks em revoke/rotate/lockdown; botão logout de emergência.
• O conjunto de testes E2E/chaos/interop foi concluído nos estandes.

Conclusão

Ao incorporar o OAuth2/OIDC como uma plataforma, você recebe fluxos de autorização previsíveis, tokens controlados, políticas de acesso unificadas e riscos mensuráveis. As ATs curtas protegidas por RT, rotação de chaves, PAR/JARM/DPoP, consentimento e step-up são práticas que tornam a segurança padrão e a evolução rápida e indolor para equipes e parceiros.