Seguridad para API REST "privada"

Question

Actualmente estoy desarrollando una aplicación web que ahora está compuesta de una interfaz que muestra e interactúa con los datos utilizando una API REST que hemos escrito. Lo único que alguna vez usará la API es nuestro sitio web front-end, y en algún momento una aplicación móvil que desarrollaremos.

He leído mucho acerca de cómo OAuth es el mecanismo ideal para asegurar una API y en este punto estoy empezando a tener una buena comprensión de cómo funciona.

Mi pregunta es: dado que nunca otorgo acceso a mi API a un cliente externo, ¿es realmente necesario OAuth? ¿Hay alguna razón por la cual es ventajoso? Además, como el back-end es simplemente la API, no hay una puerta de enlace para que un usuario se autentique (como si estuvieras escribiendo una aplicación usando la API de Twitter, cuando un usuario se autentica, sería redirigido a la página de Twitter para otorgar acceso luego redirigido de regreso al cliente).

No estoy seguro de qué dirección tomar. Parece que debe haber algún enfoque a medio camino entre la autenticación HTTP y OAuth que sería apropiado para esta situación, pero no lo entiendo.

Answer 1

2 patas OAuth es probablemente lo que desea utilizar. Básicamente, es hashing una clave compartida, pero tiene la ventaja de no tener que escribir el código usted mismo.

Aquí hay una pregunta relacionada: Two-legged OAuth - looking for information

Answer 2

que puedes usar OAuth para dispositivo móvil para la comunicación capa de API.

Sin embargo, no hay ningún beneficio de Oauth en esta capa de interfaz de usuario web para acceder a la capa intermedia (de máquina a máquina).

Por otro lado hay algunos problemas potenciales

1. la gestión del acceso caducidad de la señal se convierte en un dolor. Tenga en cuenta que su UI tiene que almacenar en caché el token de acceso en varios nodos de un clúster. Actualícelo cuando caduque, y el hecho de que la capa UI esté negociando la seguridad con el backend simplemente tomará un tiempo extra de vez en cuando.

2. En dos patas Oauth (OAuth Client Credencial como en v2.0) no es compatible con ningún cifrado. Por lo tanto, aún debe enviar la clave y el secreto al servidor para obtener un token de acceso.

3. backend tiene que implementar la emisión de token de acceso, refrescar modo, la validación de token de acceso, etc., sin ningún beneficio significativo

Answer 3

Desde mi punto de vista, uno de los escenarios que favorecen OAuth sobre otras opciones es trabaje con clientes que no sean de confianza, sin importar si los desarrolla usted o un tercero.

¿Qué es un cliente que no es de confianza? Piensa desde el punto de vista de quién maneja las credenciales que otorgan acceso a tu API.

• Por ejemplo, la aplicación web podría interactuar con el API en dos falvors:

  1. su aplicación web conversaciones lado del servidor para su API.Su servidor de aplicaciones web es un cliente confiable porque las credenciales para acceder a su API solo pueden ser accedidas por quienes tienen acceso al servidor ... Usted y su equipo. Puede autenticar su servidor de aplicaciones web con un client_id y un client_secret.
  2. Es posible que desee realizar llamadas directamente a su API desde su cliente de aplicación web, que se ejecuta en el navegador del usuario final mediante JavaScript. El navegador del usuario final es un cliente no confiable. Si fuera a entregar las credenciales a su API hasta el navegador, cualquiera podría verificar el código JavaScript y robar sus credenciales.

• Una aplicación nativa de terceros tampoco es de confianza. Un desarrollador malintencionado que use su API podría guardar las credenciales de y el usuario final de su plataforma.

• Su aplicación nativa es un cliente de confianza y podría administrar la autenticación con un simple nombre de usuario, contraseña y una identificación de cliente que identifique su aplicación.

¿Cómo puede ayudar OAuth? OAuth Authorization code y Implicit subvenciones pueden ayudarlo con este problema. Estos flujos solo funcionan con clientes que admiten una redirección, como un navegador. Y le permite autenticar a un cliente que no es de confianza y un usuario contra su Servidor de Autorización para obtener acceso a su Servidor de Recursos, su API, sin exponer las credenciales. Eche un vistazo al RFC para ver cómo se hace.

Lo bueno de OAuth es que no solo admite estos flujos de autenticación basados ​​en redireccionamiento, sino que también admite la concesión de credenciales de cliente y las credenciales de usuario. Por lo tanto, un servidor de autorización de OAuth cubriría todos los casos.

Answer 4

OAuth 2.0 parece originalmente un PITA si piensas en tener que construir mucho tú mismo, pero la mayoría de los lenguajes tienen algunas configuraciones de OAuth 2.0 realmente sólidas que puedes conectar fácilmente con diferentes formas de tocar el violín. Si está utilizando un marco como Laravel o RoR, apenas funciona.

• PHP: http://oauth2.thephpleague.com/
• Rubí (Rails o uva): https://github.com/doorkeeper-gem/doorkeeper

Si no desea redirigir a los usuarios como se sugiere en su puesto luego ignorar otros comentarios y respuestas que hablan de dos flujos de patas. Puede usar el tipo de concesión client_credentials para que las aplicaciones simplemente proporcionen su identificación de cliente y su secreto a cambio de un token de acceso, lo que es agradable y fácil.

Preguntaría qué tan privado estamos hablando, porque si los únicos sistemas que hablan están en el back-end y no tienen interacción con el mundo exterior, probablemente lo dejen abierto y solo confíen en la red para mantenerlo seguro. (VPN/Firewall).

Pero si es privado en el sentido de "nuestra aplicación de iPhone lo usa", definitivamente quiere ir con OAuth 2.0, o algo así.