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

El cliente genera un verificador aleatorio, lo convierte en un hash que es el code challenge y redirige al usuario al servidor de autorización con ese challenge. El usuario se autentica, vuelve redirigido con un código de un solo uso y el cliente intercambia ese código más el verificador original por tokens. Como el intercambio requiere el verificador, un código interceptado no sirve de nada. OAuth 2.1 exige PKCE para todo cliente, público o confidencial.

El cliente empieza generando un verificador de alta entropía y aplicándole SHA-256 para crear el code challenge. Envía al usuario al servidor de autorización con el client id, la redirect URI, los scopes, un valor state y ese challenge. El usuario inicia sesión y da su consentimiento, y el servidor de autorización redirige de vuelta con un código de vida corta. El cliente entonces envía ese código y el verificador en crudo al endpoint de tokens, el servidor aplica el hash al verificador y comprueba que coincide con el challenge que guardó, y solo entonces emite tokens. Ese es el sentido de PKCE: un código robado de una redirección, de un log o por una app maliciosa en el dispositivo no se puede canjear sin el verificador, que nunca salió del cliente. Aun así valido state por separado, porque eso cubre el CSRF en el callback y no la interceptación del código. Si estoy haciendo login en vez de acceso a una API, me importa el ID token de OIDC y valido su firma, emisor, audiencia y nonce antes de fiarme de un solo claim.