OAuth2/OpenID Connect en el núcleo

El OIDC en la parte superior de la OAuth2 es una forma estándar de probar «quién es el usuario/cliente» y emitir un acceso corto a la API. En el núcleo de la plataforma se convierte en una capacidad central: una única entrada para clientes, operadores y servicios; privilegios mínimos; riesgo medible; Cumplimiento de las normas regionales y de concesión de licencias.

1) Objetivos y principios

División «deploy vs enable»: desechamos el código por separado, habilitamos el acceso con banderas/políticas.
Tokens de vida corta + actualización segura: reduzca los daños por fugas.
Multi-tenant/región: todos los artefactos serán lanzados 'tenant/region/licence'.
Políticas sobre tokens: las soluciones hacen PDP (RBAC/ABAC), PEP en gateway/servicios.
Protección de canales: TLS1. 2 +, si es posible mTLS/DPoP, CORS/CSRF estrictos.
Observabilidad y auditoría: visibilidad por flujo, por cliente, por región.

2) Flujos y cuándo aplicarlos

Authorization Code + PKCE (SPA/Mobile/Web) es un default para los logins personalizados.
Autoridad de dispositivos (consolas/TV/CLI) - cuando no hay navegador.
Credentials de cliente (machine-to-machine): integraciones de servicio sin usuario.
Token Exchange (RFC 8693, OBO): el servicio actúa en nombre del usuario.
CIBA/Back-channel (opcional) - autenticación push sin redirección.

• Solicitudes de autorización Pushed (PAR): las opciones de autorización se transmiten a través de un canal de servidor seguro.
• JAR (JWT Secured Authorization): las opciones de consulta están firmadas/cifradas.
• JARM es una respuesta de autorización segura (JWT), resistente a sustituciones.
• RAR (Rich Authorization Requests): ricas solicitudes de derechos de acceso (permisos detallados).

3) Tokens y adhesivos

• ID Token (OIDC) - quién entró (mostrar sólo al cliente/frente).
• Access Token (AT) - Derecho a la acción (vida corta).
• Refresh Token (RT): actualiza AT; sólo se almacena en un entorno de confianza.

• 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
}

Firma: ES256/EdDSA, claves públicas - en JWKS con 'kid' y rotación.

4) Esquema de sesiones y logout

Server-side session для web (cookie `SameSite=Lax/Strict`, `HttpOnly`, `Secure`).
Back-Channel Logout + Front-Channel Logout (OIDC) es la terminación sincrónica de todos los clientes.
Step-Up MFA: con acciones sensibles - volver a comprobar ('acr' se eleva).
Revocation & Introspection: desactivación inmediata de RT/AT por incidente.

5) Seguridad del cliente

Web/SPAs: Authorization Code + PKCE, sin implícito; estrictos CORS/Content-Security-Policy.
Mobile: navegador del sistema (AppAuth), comprobación de integridad (App Attestation/DeviceCheck), almacenamiento RT protegido.
Desktop/CLI/TV: Device Flow; almacene RT en almacenes de seguridad OS.
DPoP o mTLS-bound tokens para enlazar AT a un dispositivo/conexión.

6) Servicio-a-servicio

mTLS + short Service JWT (aud-scoped), produce STS con KMS/HSM.
Identidades de workload's: SPIFFE/SPIRE.
Política "de estrecho a ancho": audience y scopes específicos en lugar de ".

7) Registro Scope y consentimiento (consent)

Nomenclatura: 'recurso: acción' - 'wallet: read', 'wallet: transfer', 'bets: place', 'kyc: status. read`.

Configure la visibilidad y sensibilidad de los Scoops.
La pantalla de consenso se ensambla desde RAR/Scopes; Mantenga su historial de consentimiento y permita la revocación.

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

8) Integración con autorización (PDP/PEP)

El PEP en la API Gateway valida AT/DPoP/mTLS, enriquece el contexto (IP/ASN/region/tenant), hace una solicitud a PDP.
El PDP (OPA/cedar) aplica políticas RBAC/ABAC/ReBAC y devuelve 'ALLOW/DENY' con explicación y TTL.
Caché de soluciones PEP (TTL 30-120 s) con discapacidad por eventos (cambio de roles/reglas).

9) Multi-tenant y regiones

Todos los tokens y sesiones están etiquetados con 'tenant/region/licence'; PDP valida la conformidad con el recurso.
JWKS/claves separadas y listas de revocación por región; región cruzada - a través de puertas de enlace de confianza.
Restricciones de residencia de datos: la introspección/revocación se realiza en la región de origen.

10) Refuerzos de protocolo

PAR + JAR + JARM: protege los parámetros y respuestas de autorización.
Nonce/State/PKCE - para todos los clientes públicos.
Authorización de dispositivos Pushed (con alto riesgo).
JWT Access Tokens con estigmas mínimos + opción opaque para integraciones externas a través de introspección.
Prácticas similares a las FAPI: algoritmos de firma estrictos, requisitos de TLS/redirect_uri/PKCE.

11) Errores y política de devolución

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 endpoints sensibles ('/token ', '/intropect', '/revoke '), backoff exponencial.

12) Observabilidad y auditoría

• `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`.
Auditoría (sin cambios): emisión de tokens, escalamiento de derechos, revocación de consentimientos, rotación de claves.

13) Gestión de claves y rotación

Firma JWT: KMS/HSM, publicación JWKS con 'kid'.
Dual-key período: IdP firma nuevo, los verificadores aceptan viejo + nuevo antes de cambiar.
Rotación regular y revoke de emergencia; monitoreo de consumo 'kid'.

14) Playbooks (runbooks)

1. Compromiso de clave de firma

Inmediatamente revoke 'kid', emitir un nuevo, RT/sesiones de discapacidad de fuerza, informe a la auditoría.

2. Masa 'invalid _ token '/crecimiento 401

Comprobar el reloj Rassynchron caducado AT, JWKS-caché roto; aumentar temporalmente el tolerance 'clock _ skew'.

3. Reutilización de RT

Bloquear sesión ('sid'), notificar al usuario, requerir paso a paso para una nueva entrada, investigación.

4. Caída de IdP

Habilitar el modo «solo lectura de autorización»: mantener el AT actual hasta TTL, restringir nuevos logins, patinar la memoria caché de introspección.

5. Ataque contra '/token '

Refuerce los filtros rate-limit/bot, incluya mTLS/DPoP para clientes sensibles, lleve los RT «fríos» a un segmento separado.

15) Pruebas

Contract: OIDC discovery, JWKS, OpenID provider config.
Seguridad: PKCE/nonce/state son obligatorios; conjuntos negatives (sustituciones de 'redamb _ uri', reuse RT).
Interoperabilidad: clientes (web/mobile/CLI), diferentes zonas horarias/locales.
Chaos: fallo PAR/JARM, retrasos JWKS, rotated 'kid' «sobre la marcha».
E2E: step-up MFA, OBO (token exchange), logout (front/back-channel), revoke/rotate.

16) Ejemplos de configuraciones

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) Lista de verificación antes de la venta

• PKCE/nonce/state incluido; PAR/JAR/JARM están activos.
• AT/RT/ID TTL especificado; RT rotation + reuse detection está habilitado.
• DPoP o mTLS-binding para clientes/operaciones sensibles.
• JWKS c `kid`; rotación automática y monitorización del consumo de llaves.
• Consent/RAR y Registro de Scoops; step-up MFA para acciones sensibles.
• PDP/PEP integrado, caché de soluciones con discapacidad.
• Los tokens contienen 'tenant/region/licence'; la residencia se respeta.
• Observabilidad: métricas, registros, rastreo; alertas en 'invalid _ token', 'rt _ reuse', 'jwks _ skew'.
• Playbucks en revoke/rotate/lockdown; botón de inicio de sesión de emergencia.
• Se ha realizado un conjunto de pruebas E2E/chaos/interop en los stands.

Conclusión

Al incorporar OAuth2/OIDC como capacidad de plataforma, obtiene flujos de autorización predecibles, tokens administrados, políticas de acceso unificado y riesgos medibles. Las AT cortas, RT seguras, rotación de claves, PAR/JARM/DPoP, consentimiento y paso a paso son prácticas que hacen que la seguridad por defecto y la evolución sea rápida e indolora para los equipos y socios.