¿Es seguro usar una URL para autenticarse automáticamente en una API protegida por OAuth?

No, este esquema que propones no es seguro, ya que potencialmente estás exponiendo tu token de autorización de dominio cruzado en los registros del servidor y referer cadenas en los servidores web de terceros desde los que estarás vinculando contenidos (o posiblemente inyectados) por XSS para inspeccionar los valores de solicitud), si lo está pasando como un parámetro URI.

En cuanto a las cookies, depende de si utilizará este token de autorización en varios dominios o en un solo dominio:

• Varios dominios : ya que necesitará que sus cookies se lean entre dominios (no limitado a un determinado path ), lo que significa que pueden ser leídas por cualquiera de sus proveedores de contenido de terceros ( cualquier contenido vinculado, incluidos, entre otros, dominios externos JavaScript, CSS, imagen, video, ... archivos) también. Una mejor manera de hacerlo sería con el uso del método HTTP POST , por lo que al menos no está exponiendo innecesariamente este token a ninguno de sus proveedores de contenido de terceros (los datos de formulario en POST son parte de la cuerpo de la solicitud y no encabezado, lo que significa que sus valores no son simplemente inspeccionables a través de servidores web).
• Dominio único : puede usar cookies para esto, pero asegúrese de que estén bloqueadas en un solo dominio en su valor path y, si es posible, use también cookies httponly (si su marco no lo hace No es compatible con trabajar directamente con este valor, simplemente puede adjuntar ;httponly al final de su valor de cookie de autorización). El uso de httponly se asegurará de que JavaScript no pueda leer estas cookies en todos los navegadores compatibles (la mayoría lo admite), eliminando así la amenaza de las inyecciones de XSS para robar sus tokens de autorización y secuestrar las sesiones de usuario.

Estas son las consideraciones que deberá tener en cuenta, independientemente de si en su pregunta quería decir que está buscando una autorización de dominio múltiple, o de dominio único:

• Los tokens no solo deben ser aleatorios, sino también únicos . Aleatorio aquí significa que no se pueden predecir conociendo ninguno de los tokens anteriores, y único significa que no solo tiene que caducar tan rápido como sea posible, sino que debe eliminarlo completamente de su grupo de tokens, y verificar la creación de token que no es repetir y con ello invalidar los tokens generados previamente que aún son válidos. Aunque la imprevisibilidad en teoría debería hacerse cargo de los últimos requisitos de exclusividad, aún es mejor asegurarse y verificar su conjunto antes de escribir un nuevo token en su base de datos.
• Probablemente querrá bloquear la validez de su token a un cliente único lo antes posible. Si bien ese cliente único puede ser un punto bastante discutible y fácil de falsificar, aún proporciona una validación adicional cuando se utilizará un único token para autorizar a un solo usuario en múltiples dominios (o en un solo dominio, cuando el usuario vuelve a enviar la solicitud de inicio de sesión por alguna razón). Le sugiero que firme cualquier información del cliente que pueda obtener con un HMAC y luego la guarde en su base de datos junto con el token En cualquier solicitud de autenticación adicional, también verifica contra esta firma de cliente HMAC para validar aún más el token utilizado.
• Quizás lo más importante es asegurarse de que todo este intercambio de token esté protegido mediante el uso de una capa de transporte encriptada , es decir, HTTPS (SSL o TLS), y eliminar MiTM escriba ataques en su proceso de autorización.