Estoy tratando de entender cómo funciona PKCE en una aplicación móvil y hay algo que no. entiendo muy bien.
Entonces, de lo que puedo recopilar, la aplicación cliente crea una cadena criptográfica segura al azar conocida como el verificador de código. Esto se almacena entonces. A partir de esto, la aplicación genera un desafío de código. El desafío de código luego se envía en una solicitud de API a un servidor junto con la forma en que se generó el desafío, por ejemplo, S256 o simple. El servidor almacena este desafío junto con un código de autorización adecuado para la solicitud en cuestión.
Cuando el cliente intenta intercambiar el código de un token de acceso, también envía el código-verificador original en la solicitud. Luego, el servidor recupera el desafío almacenado y el método utilizado originalmente para generarlo para este código en particular y genera el hash s256 / plain equivalente y los compara. Si coinciden, devuelve un token de acceso.
¿Lo que no entiendo es cómo se supone que esto reemplaza un secreto en una aplicación cliente? Seguramente, si quisiera simular esto, simplemente tomaría client_id como de costumbre y generaría su propio verificador de código y desafío, y estará en la misma posición como si PKCE no fuera necesario en primer lugar. ¿Qué está intentando resolver PKCE aquí si la idea original era que es básicamente un "secreto dinámico"? Supongo que solo está ahí si alguien está "escuchando" cuando se devuelve auth_code , pero si está utilizando SSL de nuevo, ¿es esto necesario? Se considera que reemplaza el hecho de que no debe almacenar un secreto en una aplicación pública, pero el hecho de que el cliente es responsable de generar en lugar de un servidor siente que en realidad no está ayudando allí.
