Acceso a API de terceros: ¿Realmente se requiere OAuth?

Todo se reduce al viejo adagio: "La buena seguridad de TI es difícil " .

Si no conocemos a ninguna de las preocupaciones aquí como fatales (no podemos conocer su modelo de negocio y cliente en su conjunto), plantean serias dudas o al menos cosas en las que realmente se debe pensar. acerca, y vale la pena tomar sobrio.

• Gíralo y observa la perspectiva de tus usuarios. Le está pidiendo a sus usuarios / clientes que inviertan su tiempo / dinero / recursos en el aprendizaje y el aprovechamiento de su API (caso de uso: un proveedor) en comparación con una API conocida y estandarizada (caso de uso: muchos). Si cesa la actividad se desperdicia su esfuerzo. Si desean reutilizar su propio trabajo, no pueden transferirlo o volver a solicitarlo fácilmente, sin un trabajo adicional y tal vez prohibitivo que puedan evitar al no adoptar ese camino al comienzo. Hay una razón por la que los estándares abiertos son abiertos: puede que no sean adecuados para todos, pero tienen otras ventajas en general.

• También les preocupará cuán seguros están del beneficio a largo plazo de este concepto para ellos como usuarios. Pueden considerar y evaluar la durabilidad de su negocio, su enfoque, su compromiso con este camino y su compromiso con este camino, y en algún nivel evaluarán qué tan seguros están de usted y del producto y su uso. El producto seguirá existiendo en los próximos años (muchos no). ¿Qué pasa con la interoperabilidad? Quizás sea una preocupación si a sus otros proveedores les interesa incluir alguna API propietaria y menor o una conocida que puedan vender como una característica a otros usuarios suyos, o si se pueden obtener datos. en otros paquetes sin tener que escribir "cuñas" para cada uno. ¿Querrán la carga de mantenimiento o las dudas que esto pueda generar?

• En tercer lugar, incluso si la gente estuviera interesada en ello, considere esto también: ¿qué base tiene para creer que su enfoque sería más seguro implementado que las versiones existentes? Eso no es lo mismo que "más seguro diseñado". Una configuración hecha en casa puede ser mucho mejor adaptada y adecuada para sus necesidades, pero confía en que tiene la competencia y las habilidades para diseñar, y desarrollar una implementación de ese diseño , que se enfrentará a la ¿El mundo real de ITSec? Incluso si crees que puedes, ¿los terceros cuya confianza deseas utilizar, estarían de acuerdo contigo?

• Cuarto, considere que un marco que tiene su propio enfoque de desarrollador, puede responder de manera más rápida y confiable a los cambios en el mundo de seguridad que lo afectan, o en el lado positivo, los nuevos estándares / desarrollos emergentes. ¿Tiene los recursos en su negocio para comprometerse a mantener un enfoque en mantenerlo actualizado continuamente, una vez producido? (Podrías, no has descrito el negocio). Planifique una mayor pérdida de recursos de lo esperado.

La redacción de su pregunta es reveladora, y debe ser la pieza final que necesita:

  

Dudo > > si realmente son necesarios < < para nuestro uso previsto. Creo que la implementación > > más simple ... podría hacer el trabajo también < <

En otras palabras, parece que no está convencido de que haya algún inconveniente real, excepto que pueden tener características y competencias adicionales que no necesita. Pero aún así puede valer la pena utilizar el paquete incluso si no necesita todo lo que tiene, debido a sus otras muchas ventajas al hacerlo. Después de todo, pocas personas usan las características "más" de los principales programas de cualquier (el humilde MS Word a través de los servidores web de Apache son ejemplos rápidos) y aún así se usa el software, pero no todas las funciones.

Como empresa, es probable que su objetivo se base en la confianza (suyos + clientes), la velocidad y la eficiencia de costo / tiempo. Para la mayoría de las empresas que consideran una necesidad de seguridad, una solución ya preparada puede vencer de manera rutinaria las tareas de propiedad propia en todos los frentes principales, incluso si es más de lo que necesitan en la actualidad.

No leí todos los detalles que escribiste, solo quiero hacer una observación general: estás planeando que re-implemente parte de un estándar existente. Lo más probable es que en unos pocos meses se dará cuenta de que necesita otra característica y tendrá que volver a implementar un poco más de ese estándar. A menos que sea un genio criptógrafo con un equipo dedicado de revisores, es muy probable que cometa un error (o muchos de ellos) en el camino, ya sea en el diseño o en la implementación.

Y además, está obligando a todos los terceros a aprender algo nuevo que es único en su sitio. Por lo tanto, un tercero que ya sabe cómo integrar OAuth no obtiene ningún beneficio de su conocimiento y tiene que dedicar mucho tiempo a aprender su esquema en lugar de simplemente hacer el trabajo; si no ya saben OAuth, no obtienen el beneficio de aprenderlo ahora y poder reutilizar ese conocimiento la próxima vez. De cualquier manera, los terceros tienen que dedicar tiempo a aprender su método único de autenticación en lugar de desarrollar nuevas características geniales: ¿por qué deberían desarrollar algo que le ayude a usted en lugar de desarrollar algo para uno de sus competidores que creó integración más fácil?

NIH es una mala trampa para caer. Solo usa lo que ya existe.

Además de las respuestas más orientadas a los negocios que ya se dieron, creo que también hay un beneficio técnico al utilizar OAuth:

Una vez que la aplicación de terceros (cliente OAuth) haya obtenido el token de acceso OAuth, pueden usarlo para realizar solicitudes tanto desde el navegador (por ejemplo, mediante solicitudes AJAX) como desde su servidor. (Corrígeme si esto está mal ...)

Con la solución personalizada que propuse, solo serían posibles las solicitudes desde el navegador: la aplicación de terceros nunca obtiene ningún token de acceso, solo utiliza de manera implícita la cookie de sesión de nuestro sitio web sin saberlo. Esto reduciría el poder de nuestra API, ya que obligaría a los desarrolladores a una arquitectura particular. El navegador siempre será requerido como "proxy" para pasar datos entre nosotros y su backend.