Encontró cómo obtener Oauth2 client_id a lo largo del secreto coincidente, pero redirect_uri está en la lista blanca como requisito. ¿Sigue siendo seguro?

Si obtiene un OAuth 2.0 client_id junto con un secret coincidente, en teoría puede hacerse pasar por el sitio web objetivo.

1. Usted engaña a la víctima para que visite su URL;
2. A través de client_id y OAuth 2.0 secret coinciden, se registran silenciosamente en segundo plano; El sistema OAuth 2.0 redirige al proveedor OAuth 2.0 desde la primera página web, luego el proveedor OAuth 2.0 redirige al valor del parámetro redirect_uri (que generalmente redirige al sitio web que inició el inicio de sesión). El proceso establece una cookie de sesión que se utiliza tanto para la autenticación en el sitio web como para interactuar con la API del proveedor de OAuth 2.0.
   Dependiendo de la situación, si el usuario ya ha iniciado sesión en el sitio web real y en el proveedor de OAuth 2.0, puede conectarse al sitio web del atacante sin tener que ingresar ninguna credencial o hacer clic en cualquier cosa . Así que esto funciona silenciosamente como un ataque XSS desde la perspectiva del usuario.
3. Debido a que el usuario confía en el sitio web real con las credenciales robadas de OAuth 2.0, él / ella autorizó el sitio web para acceder a los datos del proveedor de OAuth 2.0. Pero como el atacante puede suplantar técnicamente el sitio web de destino a través de una cookie de sesión, el atacante puede reutilizar la autorización de confianza en el parámetro de alcance.

Pero en mi caso, el proveedor de OAuth 2.0 requiere configurar una lista blanca para el parámetro redirect_uri , por lo que es imposible redireccionar directamente.

Aunque aprovechar una redirección abierta completa en el sitio web real puede llevar a una amenaza real, me pregunto si las cosas se mantendrán seguras siempre y cuando esa segunda vulnerabilidad no se aproveche. https://tools.ietf.org/html/rfc6749"> de acuerdo con la especificación rfc6749 .