OAuth 2.0: qué es, cómo funciona y por qué usa PKCE

OAuth 2.0 es un marco para que una aplicación obtenga acceso limitado a un recurso en nombre de una persona. En vez de pedirle la contraseña de otro servicio, la aplicación deriva al usuario a un servidor de autorización. Allí la persona aprueba permisos y vuelve con un resultado que la aplicación puede canjear por un token.

También puede servirte: Qué es un webhook y en qué se diferencia de una API

La separación es importante: OAuth habla de autorización, es decir, qué puede hacer un cliente con un recurso. No es por sí mismo un protocolo de identidad. Para saber quién inició sesión se suele agregar OpenID Connect, que usa OAuth como base y define un identificador y un token de identidad.

El permiso debe ser específico. Una aplicación que sólo necesita leer el calendario no debería solicitar escritura sobre todos los archivos. Los alcances o scopes documentan ese límite y permiten que el servidor de recursos rechace una operación que no fue autorizada.

La especificación RFC 6749 describe cuatro roles. El propietario del recurso es la persona que concede acceso; el cliente es la aplicación que lo solicita; el servidor de autorización emite códigos y tokens; y el servidor de recursos protege la API que se quiere usar. Una misma empresa puede operar varios roles, pero conviene mantenerlos conceptualmente separados.

En el flujo de código de autorización, el cliente envía al navegador al servidor de autorización con su identificador, una redirect URI y los scopes. La persona se autentica allí y aprueba. El servidor devuelve un código breve a la redirect URI. Ese código no es todavía permiso para llamar a la API: el cliente lo canjea en el servidor de autorización por un access token.

La aplicación usa el access token para llamar al servidor de recursos, normalmente en el encabezado Authorization. El token debe tener una duración y unos scopes que limiten el daño si se filtra. Cuando expira, el cliente puede usar un refresh token si el flujo y la política del proveedor lo permiten.

PKCE, definido en RFC 7636, agrega un verificador secreto creado por el cliente y un desafío derivado de ese verificador. El cliente envía el desafío al iniciar la autorización. Cuando recibe el código, lo canjea junto con el verificador original. El servidor sólo entrega el token si ambos coinciden.

La protección evita que una aplicación que logró observar el código pueda canjearlo sola. El código circula por una redirect URI y puede quedar expuesto en registros o en una aplicación móvil mal aislada; el verificador nunca debe viajar en ese primer paso. PKCE no reemplaza HTTPS, una redirect URI exacta ni la validación del estado.

Para una aplicación pública, la implementación habitual usa el método S256: calcula un hash del verificador y lo codifica para formar el desafío. El proveedor debe rechazar métodos débiles o ausentes cuando el cliente está obligado a usar PKCE. Esta decisión se verifica en la documentación de cada servidor de autorización.

Registrá redirect URIs exactas y evitá comodines. En una aplicación móvil usá el flujo recomendado para apps nativas de RFC 8252, con un navegador externo y un mecanismo de retorno que no permita a otra aplicación apropiarse del código. En una web, conservá el cliente secreto sólo en el servidor y nunca en JavaScript enviado al navegador.

Generá un state impredecible y comprobalo al volver para vincular la respuesta con la solicitud que inició tu aplicación. Validá issuer, audiencia, expiración y scopes del token antes de usarlo; no aceptes un JWT sólo porque se puede decodificar. Guardá refresh tokens con el mismo cuidado que una contraseña y revocalos cuando cambie la sesión.

Por último, probá rechazos: redirect URI alterada, state incorrecto, código reutilizado, verificador PKCE que no coincide y token vencido. Documentá qué permisos pide cada función y qué ocurre si el usuario los revoca. OAuth simplifica la autorización, pero la seguridad depende de estas decisiones y de la configuración del proveedor.