Registro del cliente OAuth2: ¿debería redirect_uri ser único entre los clientes?

Realmente no hay una buena manera de garantizar de manera segura que un cliente sea lo que dice que es, por lo que realmente no tiene sentido intentar que cada URI de redireccionamiento sea único para un solo cliente. Para empezar, la única razón por la que registra URI es para evitar el escenario de redireccionamiento abierto que se menciona en la documentación, lo que hace que sea trivial decirlo, configurar un cliente malvado al que se redirige después de la autenticación, lo que le permite enmascararse como un cliente benigno. No resuelve problemas como el envenenamiento de DNS o las modificaciones del archivo del host.

Dado que no hay forma de garantizar que un cliente sea el mismo solicitante que la última vez que realizó una solicitud, debido a la naturaleza sin estado de los servidores HTTP, lo que esto significa a largo plazo es que tendrá que emitir un Mire cada vez que el cliente quiera conectarse por un canal lateral seguro y autorice la solicitud de esa manera. Para los clientes privados, eso puede ser imposible, porque alguien podría descubrir cómo hacerlo mediante la ingeniería inversa de la aplicación que hace esto. Para los clientes públicos, esto sería factible, pero agregaría complejidad adicional y un pequeño retraso para cada solicitud.

No hay un escenario que haga que una restricción de cliente única sea más segura que no tener una regla de este tipo, ya que cualquier forma que pueda usarse para evitar una también podría usarse para evitar la otra, solo agrega una capa de oscuridad. En el caso de un cliente privado, ni siquiera se ralentizaría trivialmente a un determinado atacante, y los clientes públicos están protegidos por otros medios de todos modos (incluido un secreto de cliente , un tipo de contraseña que solo ese cliente debería saber).

Tenga en cuenta que imponer la singularidad en realidad causa una variedad de problemas.

El ejemplo más simple es que estás restringiendo quién puede usar https://localhost:8080/ para un solo cliente. Cualquier otro cliente que intente usar https://localhost:<port>/ tendría que jugar un juego de adivinanzas con puertos para encontrar un URI disponible.

Además, está estableciendo una forma de reclamación de un dominio al hacer esto. A menos que esté usando algo como ACME para imponer que los clientes realmente posean los URI que están registrando, usted estamos permitiendo a un cliente reclamar un URI que no es de su propiedad. Un cliente descuidado (o malicioso) podría registrarse para URI como https://www.whitehouse.gov/oauth_redirect . Si real whitehouse.gov aparece para registrar un URI, ese valor ya no está disponible, y no hay forma de quitar ese URI del otro cliente.

Tal colisión no es necesariamente una ocurrencia accidental probable en diferentes instituciones, pero whitehouse.gov puede registrar múltiples clientes. Aquí se encuentra con otros problemas: si whitehouse.gov quiere hacer la transición de un cliente a otro sin cambiar un URI de redirección, no pueden hacerlo.

También expresaría una leve y general preocupación por el supuesto de que ver un URI de redirección dado significa definitivamente que el servicio está interactuando con un cliente específico. Tal suposición no puede ni debe hacerse.

Los URI de redireccionamiento no necesitan ser, ni deberían ser, globalmente únicos. Solo deben ser únicos dentro del perfil de un cliente. Los URI de redireccionamiento no se corresponden necesariamente con una dirección física real. Simplemente deben ser comprendidos por el cliente y verificados por el servidor.

Sin embargo, las ID de cliente deben ser únicas a nivel mundial.

Cuando un cliente solicita autorización, debe proporcionar su ID de cliente y redirigir el URI.

Si estoy creando una aplicación de navegador del cliente, mi URI de redireccionamiento del desarrollo probablemente será algo como enlace , no debería importar si resulta que alguien más ha usado este mismo URI de redireccionamiento.