Flujo Authorization Code con PKCE
Generado automáticamente desde el archivo fuente. No editar a mano — vuelve a ejecutar
catalyst-changelog-sync.
Qué cambió
Sección titulada «Qué cambió»- Añade
GET /api/o-auth/authorize(RFC 6749 §4.1): valida el cliente, compara elredirect_uricontra el registrado de forma exacta, exige unstateno vacío, obliga a PKCE y hace un 302 de vuelta con uncodede un solo uso y vida corta. - Amplía
POST /api/o-auth/tokencon un tercer grant —authorization_code— que se canjea con uncode_verifiermediante HTTP Basic. Los códigos son de un solo uso (se marcan de forma atómica) y caducan en ~60s; el PKCE S256 se verifica en el canje. - Añade una cookie
hub_session(JWT RS256 httpOnly) para que el usuario autenticado no tenga que volver a identificarse; una petición a authorize sin sesión rebota al/sign-in?continue=…del hub.
Por qué importa
Sección titulada «Por qué importa»El hub es ahora un proveedor OAuth2 Authorization Code completo, así que las apps satélite pueden delegarle el login en lugar de chocar con 404 Cannot GET /api/o-auth/authorize. El PKCE S256 es obligatorio y el endpoint de authorize falla en cerrado — nunca redirige ante un error de validación, eliminando la superficie de open-redirect. Los grants Password y Refresh Token quedan intactos, de modo que los clientes de token existentes siguen funcionando. La autorización sigue basándose en permisos (dPermissions vía iamMeAccount); el scope de OAuth es un passthrough cosmético y no concede nada.