¿OAuth es una buena opción para la API RESTful en este escenario de SaaS?

Question

¿Es sensato utilizar OAuth cuando la información de la cuenta de usuario (identificaciones de usuario, contraseñas, roles, etc.) se mantendrá en nuestro propio back-end y cuando no habrá ningún intercambio de recursos con otros sitios? ¿O está compartiendo el objetivo de usar OAuth?

Antecedentes:

estoy trabajando en el desarrollo de un producto SaaS de la empresa y estamos creando una API REST para ser utilizado por nuestras aplicaciones de front-end. Los consumidores de la API serán aplicaciones de navegador y de teléfono inteligente nativo (iOS & Android) que desarrollamos. Dado que admitiremos varios tipos de clientes, tiene sentido crear una API RESTful que todas nuestras aplicaciones cliente puedan consumir.

Naturalmente, necesitamos asegurar esta API RESTful. Estamos considerando la autenticación mediante HTTPS/Basic Auth, pero conocemos algunos de los inconvenientes conocidos de este enfoque.

Algunas investigaciones rápidas muestran que OAuth es muy recomendable. Pero la mayoría de lo que encuentro con OAuth se encuentra en el contexto de la autorización de sitios web para compartir información en nombre del usuario.

Cualquier información si es bienvenida.

Answer 1

Buena pregunta, y vamos a tener una buena discusión sobre esto durante al API Craft:

https://groups.google.com/group/api-craft/browse_thread/thread/b87fd667cccb9c00

Aquí está la respuesta que he publicado allí:

Creo que este es un buen uso caso de OAuth, en realidad.

En primer lugar, con OAuth su aplicación móvil puede almacenar un token de OAuth en el cliente en lugar de la contraseña "real" del usuario.Por lo tanto, puede hacer que la aplicación "inicie sesión automáticamente al usuario" obteniendo un token de OAuth sin tener que almacenar la contraseña real en el dispositivo. Si el usuario pierde el dispositivo o si se ve comprometido de alguna manera, ellos (o usted) pueden borrar el token de OAuth sin que el usuario tenga que cambiar la contraseña y deshacerse de otras cosas que podrían estar haciendo con su API. Hay ejemplos similares para una aplicación web estilo Ajax, pero depende más de la forma específica en que construya el cliente.

En segundo lugar, el token de OAuth está asociado con una clave única que identifica la aplicación que realiza la llamada API y que a su vez identifica qué desarrollador creó la aplicación. Eso le da opciones como rastrear el uso por aplicación, desactivar una aplicación que podría haberse comprometido sin desactivar toda la API, y si alguna vez desea abrir el acceso a terceros o socios que crean aplicaciones para su API, puede ofrecer diferentes niveles de servicio a otros clientes.

En tercer lugar, sus empleados de seguridad de TI estarán encantados si les dice que nunca almacena una contraseña en el dispositivo móvil del usuario ni la esconde en algún lugar de su navegador.

En cuarto lugar, tiene la opción de inicio de sesión basado en el navegador para la aplicación móvil. Eso significa que la aplicación móvil nunca verá la contraseña del usuario, y también que si desea implementar seguridad de dos factores o algo así, puede hacerlo en la pantalla de inicio de sesión sin cambiar las aplicaciones móviles. Ahora, el inconveniente es que el usuario ve una ventana del navegador emergente. Es por eso que OAuth le brinda diferentes maneras de obtener un token de acceso para una aplicación, de modo que puede elegir si necesita tener un inicio de sesión basado en el navegador o hacer que el usuario ingrese su contraseña directamente en la aplicación.

En quinto lugar, ¿cómo sabes que tu API solo será utilizada por tus propias aplicaciones? Si usa OAuth ahora, le resultará más fácil realizar esa transición más adelante.

Answer 2

OAuth es solo un token y la aplicación solicitante emitirá uno. Puede leer más en pingidentity.com donde también hay varios seminarios web sobre este tema (identidad de la nube y aprovisionamiento de usuarios).

Answer 3

Implementé un OAuth para Django nonrel con pistón para exponer mis API al consumidor. Hay varios tipos en OAuth (2 patas 3 patas).

Generalmente, admitir OAuth es un desafío bastante grande. Debe obtener el token de solicitud, autorizarlo y almacenar el token de acceso para firmar cada solicitud que desee autenticar.

Ventajas
- Usted no tiene que enviar nombre de usuario y contraseña cada vez, seguro.
- Permita que un tercero consuma su aplicación.
Desventajas
- Haga 2,3 viajes de ida y vuelta para autenticarse.
- Complicado para implementarlo usted mismo.

Estoy bastante seguro de que puede encontrar una serie de bibliotecas que le permiten:
- Exponga su Api y soporte OAuth. E.g pistón Django.
- Firme sus solicitudes agregando encabezados a ellas. E.g Oauth-signpost.

Answer 4

Sí, este es un muy buen ajuste para OAuth. Todavía puede usar HTTP Basic sobre SSL durante el intercambio de palabras para la autenticación. La salida del handshake de OAuth será un token que luego podrá usarse para consumir la API. De esta forma, la aplicación no necesita almacenar las credenciales y los tokens pueden ser fácilmente revocables con un impacto mínimo para el usuario.

OAuth 2.0 define una serie de diferentes tipos de concesiones para adaptarse a diferentes situaciones. Me parece que las credenciales de contraseña "implícita" o "propietario de recursos" son las más apropiadas, pero es posible que desee considerarlas cuidadosamente.

No debe implementar esto directamente en su API, sino utilizar la infraestructura para delegar el soporte de OAuth y la administración de tokens en nombre de su API de SaaS.

Tome un vistazo a

http://www.layer7tech.com/blogs/index.php/oauth-token-management-2/

y

http://www.layer7tech.com/products/oauth-toolkit

Esperanza esta ayuda,

"contexto de la autorización .."

-fl