Autenticación y autorización

Un circuito AuthN/AuthZ fiable es un único punto de verdad sobre quién eres (autenticación) y qué se te permite (autorización). En una plataforma con multitud de marcas, regiones, integraciones y altas exigencias regulatorias, este circuito debe ser modular, observado y gestionado por las políticas, en lugar de ser un «relleno de si-servicios».

1) Términos y roles básicos

Identificación (ID): identificación (usuario, servicio, proveedor).
Autenticación (AuthN): prueba de identidad (contraseña, MFA, certificado).
Autorización (AuthZ): la decisión «se puede/no se puede» basada en políticas y contexto.
PDP/PEP: Punto de decisión de la política (toma la decisión )/Punto de decisión de la política (aplica).
IdP: Proveedor de identificación (OIDC).
Subject/Resource/Action/Context: quién/a qué/qué hace/bajo qué condiciones.

2) Arquitectura de contorno general

[ IdP (OIDC) ]
│ OIDC/OAuth 2. 1 (PKCE, JAR/JARM)

[ Token Service / JWKS / KMS ]
│klyuchi (rotate)
│ JWT/Access/Refresh, mTLS

[API Gateway (PEP)] Solution/Policy ──kesh
│ authN/CSRF/CORS/rate-limit

[ Microservices (PEP)]──PDP (OPA/cedar) ──Policy Store (GitOps)
│audit/metriki

[ Data/Providers ]── service-to-service (mTLS+JWT/Spiffe)

Principios: centralización de la generación de tokens y políticas, aplicación local; «privilegios mínimos» y delegaciones explícitas.

3) Autenticación de usuario (OIDC/OAuth 2. 1)

• Authorization Code + PKCE (siempre para SPA/Mobile).
• SSO: soporte de IdP externo (SAML/OIDC) para b2b/operadores.
• MFA: TOTP/WebAuthn/SMS (recomendado por WebAuthn y TOTP; SMS — fallback).
• Risk-based Step-Up: en acciones sensibles (retiros, cambios de datos), requiere MFA/pe-Auth.

• Refresh Token Rotation + registro RT con el detalle de reutilización.
• Nonce/State + PKCE, un CORS/CSRF estricto para flujos de navegador.
• Short-lived access tokens (5–15 мин) + silent refresh/RT.
• Device binding (DPoP/mtls-bound tokens) para operaciones críticas.

json
{
"iss": "https://auth. example. com",
"sub": "user_9f12",
"aud": ["wallet","catalog"],
"exp": 1730385600,
"iat": 1730384700,
"tenant": "brand_eu",
"region": "EE",
"amr": ["pwd, ""webauthn"] ,//authentication methods
"scp": ["wallet:read","bets:place","kyc:status. read"],
"sid": "sess_a1b2c3",      // session id
"acr": "urn: mfa: strong "//warranty level
}

4) Servicio de autenticación (mTLS, SPIFFE, JWT)

mTLS entre servicios + SPIFFE/SPIRE para identificadores de workload's sostenibles.
Servicio JWT a corto plazo (≤5 min), firmado por HSM/KMS; Auditoría de la emisión.
Audience-scoped: JWT sólo es adecuado para un servicio/dominio específico.
Zonas de confianza: servicios de otra región/tenant - PKI y políticas individuales.

5) Modelos de autorización: RBAC, ABAC, ReBAC

RBAC (roles → resolución): simple y transparente (adecuado para paneles de administración, operadores).
ABAC (atributos sujeto/recurso/contexto): flexible para reglas "tenant =... AND region=… AND kyc_tier≥2».
ReBAC (relaciones): útil para posesiones complejas («quién posee la marca/carpeta/campaña»).

Recomendación: híbrido - RBAC básico + condiciones ABAC contextuales + relaciones ReBAC puntuales.

6) Políticas y su ejecución (PDP/PEP)

PEP en Gateway y en los servicios: extrae el contexto (JWT, mandatos, IP/ASN, tiempo, región, nivel KYC), forma la solicitud a PDP.

json
{
"subject": { "sub":"user_9f12", "roles":["support"], "kyc":2, "tenant":"brand_eu" },
"action": "bets. place",
"resource": { "game_id":"g_42", "provider":"pr_x" },
"context": { "region":"EE", "ip_asn":"AS12345", "time":"2025-10-31T12:34:56Z" }
}

y devuelve 'ALLOW/DENY' + explicación.

La caché de soluciones PEP (TTL 30-120 c) reduce la latencia; discapacidad por eventos de «cambio de roles/políticas».

rego package bets

default allow = false

allow {
input. action == "bets. place"
input. subject. kyc >= 2 input. subject. tenant == input. context. tenant not blocked_region within_limits
}

blocked_region { input. context. region == "NL" }
within_limits { input. context. bet_amount <= data. limits. max_bet[input. subject. tenant] }

7) Escopetas y permisos

• Recurso: acción - 'wallet: read', 'wallet: transfer', 'bets: place', 'kyc: status. read`.
• Para administradores - 'admin:' en un dominio aislado.
• Para proveedores - 'provider: report. read`, `provider:events. push`.

El principio de los privilegios mínimos: asignamos sólo los scoups necesarios; «escaladas» (extensiones temporales de derechos) - por ticket y con TTL.

8) Multi-tenant y regiones (residency)

Las señales contienen 'tenant', 'region', 'licence'; PDP comprueba la conformidad con el recurso.
Roles/directivas: espacios de nombres per tenant ('role: brand _ eu/support').
Divide las claves de firma y las listas de revocación por región; consultas entre regiones - sólo a través de puertas de enlace de confianza.

9) Gestión de sesiones y dispositivos

Server-side session store para web (enlace a dispositivo/navegador, rotación de ID).
Idle/Absolute Timeout (por ejemplo, 30 min/24 h); acciones sensibles - re-Auth/MFA.
Lista de dispositivos activos, «salir de todos».
Anomalías: entradas simultáneas de diferentes regiones, fallas frecuentes de MFA - señales de riesgo.

10) Delegación y consentimiento (consent)

On-behalf-of (OBO): el servicio actúa en nombre del usuario (un token proxy con una 'sub '/' act' separada).
Consentimiento: pantalla explícita para el acceso del socio a los datos, registro de consentimiento para la revocación.
Access-mandates temporales: los derechos de N horas/días, expiran automáticamente.

11) Claves, firmas y rotación

JWKS con 'kid', rotación automática, almacenamiento de claves privadas en KMS/HSM.
Algoritmos: ES256/EdDSA para JWT; TLS 1. 2+/mTLS.
Dual-key período: recepción de ambos 'kid' antes de completar la actualización de clientes.
Reseña de RT y Token Introspection para incidentes críticos.

12) Seguridad de aplicaciones cliente

SPA: Authorization Code + PKCE, no `implicit`, строгий CORS/Content-Security-Policy.
Mobile: App Attestation/Device Check, almacenamiento RT seguro, protección de Ruth/jailbreak.
Desktop: navegador del sistema para inicio de sesión (no embedded web-views), PKCE.

13) Contratos de conveniencia SDK

http
POST /authz/evaluate
Authorization: Bearer <access_jwt>
Body: { "action":"bets. place", "resource":{"game_id":"g_42"}, "context":{"bet_amount":5. 0} }
→ 200 { "decision":"ALLOW", "ttlMs":60000, "explain":"kyc>=2, limit ok" }

http
POST /oauth/token grant_type=urn:ietf:params:oauth:grant-type:token-exchange subject_token=<user_jwt>&actor_token=<service_jwt>&audience=wallet

14) Observabilidad y auditoría

• `authn_success_rate`/`mfa_challenge_rate`/`mfa_fail_rate`
• `authz_p95_ms`, `authz_denied_rate{reason}`
• `invalid_token_rate`, `jwks_skew_ms`, `rt_reuse_detected`
• Anomalías de entradas (nuevo dispositivo, geo-velocidad), escopetas sospechosas.

• `who/what/when/where/why`, `decision`, `policy_version`, `token_kid`, `client_id`.
• Exportación para cumplimiento (regulador/auditoría de proveedores).

15) Protección del perímetro y del cliente

Gateway PEP: rate-limit, bot/signature checks, protección CSRF, CORS estricto, HSTS.
Tráfico interno: mTLS + JWT de servicio + redes limitadas.
Webhooks/collbacks externos: firmas corporales (HMAC/JWS), ventanas de tiempo, anti-réplica.

16) Errores típicos

Tokens de acceso de larga vida → fugas.
Flujo implícito de OAuth en el SPA.
No hay rotación de llaves y periodo Dual-Key.
Funciones definidas en lugar de políticas (no se pueden auditar ni explicar soluciones).
Mezcla de tenantes/regiones en un solo 'role' o 'key'.
No hay MFA de paso a paso en las acciones sensibles.
Caché de soluciones AuthZ sin discapacidad para cambios de rol.

17) Playbooks (runbooks)

1. Compromiso de clave de firma JWT

Revoke inmediato 'kid', publicación del nuevo JWKS, discapacidad forzada RT/sesiones, informe a la auditoría.

2. Masa 'invalid _ token'

Comprobar el reloj/tiempo de vida Rassynchron, la relevancia de JWKS, fallas de caché.

3. Anomalías de las entradas

Habilitar el aumento de riesgo-puntuación, requerir paso a paso, notificar al usuario, limitar temporalmente los pagos.

4. Error de IdP

Cambiar a caché de sesión/rol-dispositivo, limitar nuevos logins, mantener las sesiones actuales hasta TTL.

18) Lista de verificación antes de la venta

• OIDC/OAuth 2. 1 con PKCE, AT corto, rotación RT, device binding para operaciones críticas.
• MFA (WebAuthn/TOTP) y step-up para pines/cambios de datos/rol-escalaciones.
• Servicio a servicio: mTLS + SPIFFE, JWT de servicio de corta duración.
• Políticas AuthZ (RBAC + ABAC/ReBAC) en PDP centralizado; PEP en gateway y en servicios.
• Caché de soluciones para discapacitados; audit trail inmutable.
• Multi-tenant/regiones: aislamiento de claves/políticas/registros, contabilidad de licencias.
• JWKS/llaves en KMS/HSM, rotación dual-key, monitoreo 'kid'.
• Filtros CSRF/CORS/HSTS/Rate-limit/bot en el perímetro.
• Playbooks de incidentes, run-botones revoke/rotate/lockdown.
• Conjunto de pruebas: unidad (políticas), contrato (SDK/flows), chaos (IdP, JWKS), e2e (step-up, OBO, revoke).

19) Mini plantillas de configuración

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

yaml deny:
- when: { region: ["NL","BE"] }
actions: ["bets."]

El esquema de autenticación y autorización no es una biblioteca, sino una capacidad de plataforma: tokens de vida corta y claves administradas, políticas centralizadas y su aplicación local, multifactor y step-up, aislamiento estricto de tenantes/regiones, auditoría y telemetría. Este diseño hace que los cambios sean seguros, explicables para el regulador y transparentes para el producto - y el escalamiento por mercados y equipos se convierte en una operación rutinaria en lugar de una hazaña.