OAuth 2.0, PKCE, JWT, JWK y JWKS: entender sus funciones

OAuth 2.0, PKCE, JWT, JWK y JWKS suelen aparecer en la misma arquitectura, pero no son equivalentes. Algunos conceptos describen flujos de autorización; otros, un formato de token o una forma de representar claves criptográficas.

OAuth 2.0 organiza la autorización

OAuth 2.0 es un marco de autorización delegada. Permite que una aplicación obtenga acceso limitado sin pedir al usuario la contraseña de otro servicio.

OAuth no exige que todos los access token sean JWT. El formato del token es una decisión aparte.

PKCE protege el intercambio del código de autorización

PKCE añade una prueba temporal al flujo Authorization Code. El cliente crea un code_verifier aleatorio y envía previamente un challenge derivado. Al intercambiar el código recibido debe presentar el verifier original.

El generador PKCE permite visualizar verifier, challenge y la transformación S256.

PKCE no cifra un JWT ni sustituye TLS. Protege una fase concreta del flujo de autorización.

JWT es un formato de token

JWT define una estructura compacta formada por segmentos separados por puntos. Los JWT firmados pueden incluir claims y una firma verificable.

El inspector JWT, el decodificador JWT y el codificador JWT facilitan su análisis.

Decodificar un JWT no equivale a verificar su firma. El payload de un JWT normal no debe tratarse como confidencial solo porque esté codificado.

JWK y JWKS representan claves

JWK es una representación JSON de una clave criptográfica. Un JWKS es un conjunto de JWK que suele publicarse para que los clientes obtengan las claves públicas necesarias para verificar firmas.

El inspector JWK/JWKS ayuda a revisar tipo, identificadores y parámetros.

Un encabezado JWT puede incluir un kid, que permite seleccionar la clave correspondiente del JWKS.

Cómo encajan las piezas

1. el cliente inicia OAuth y crea valores PKCE;
2. el servidor de autorización autentica al usuario y devuelve un código;
3. el cliente intercambia ese código presentando el verifier;
4. el servidor devuelve tokens, que pueden ser JWT;
5. el destinatario lee el encabezado y selecciona una clave del JWKS;
6. verifica la firma y aplica issuer, audience, expiración y demás reglas.

Confusiones habituales

• OAuth no es un formato de token.
• PKCE no es cifrado.
• El payload de un JWT no es automáticamente confidencial.
• Decodificar no es verificar una firma.
• JWKS es un conjunto de claves, no una lista de sesiones.

La clave es distinguir protocolo, contenedor y claves.