Explícame el flujo de código de autorización de OAuth 2.0.

OAuth 2.0 confunde a muchos candidatos porque lo mezclan con el inicio de sesión. OAuth trata de la autorización delegada —permitir que una aplicación actúe sobre un recurso en nombre del usuario— y no de identificar al usuario (eso es OIDC, montado encima). El flujo de código de autorización es la opción segura por defecto.

El flujo, paso a paso

1. Redirección a autorizar. La aplicación envía el navegador del usuario al servidor de autorización con su ID de cliente, los ámbitos solicitados, una URI de redirección y un valor state (protección CSRF).
2. El usuario se autentica y consiente. El usuario inicia sesión en el servidor de autorización —la aplicación nunca ve la contraseña— y aprueba los ámbitos solicitados.
3. Código devuelto. El servidor de autorización redirige de vuelta a la URI registrada de la aplicación con un código de autorización de corta duración y de un solo uso en la cadena de consulta.
4. Intercambio por canal trasero. El backend de la aplicación envía ese código, más su secreto de cliente, al endpoint de token y recibe un token de acceso (y a menudo un token de refresco). Este paso ocurre de servidor a servidor, no en el navegador.
5. Llamar a la API. La aplicación usa el token de acceso como credencial portadora para llamar al servidor de recursos.

Por qué este diseño

La idea clave es que el potente token de acceso nunca viaja por el navegador ni por una URL, donde podría registrarse, almacenarse en caché o filtrarse vía cabeceras de referente. Solo lo hace el código de bajo valor y corta duración, y el código es inútil sin el secreto de cliente. Por eso el flujo de código se prefiere sobre el ahora obsoleto flujo implícito, que exponía los tokens directamente en la redirección.

PKCE para clientes públicos

Las aplicaciones móviles y las SPA no pueden guardar un secreto de cliente. PKCE (Proof Key for Code Exchange) lo soluciona: el cliente envía un code_challenge aleatorio hasheado al principio y el code_verifier correspondiente en el intercambio de token, probando que el mismo cliente que inició el flujo lo está terminando, de modo que un código robado no puede ser canjeado por un atacante.

Qué buscan los entrevistadores

La secuencia redirección/consentimiento/código/intercambio-por-canal-trasero, la razón por la que los tokens se mantienen fuera del navegador, el flujo de código sobre el implícito, y PKCE para clientes que no pueden guardar un secreto. Punto extra por notar que OAuth es autorización y OIDC es autenticación.