ruby on rails - rails - Ventajas de usar OAuth Password Credentials Grant sobre Token Access Authentication

rails 5 api authentication

Question

Estoy creando una API para una aplicación móvil utilizando Rails 5. Por el momento, no necesito la autorización de tres patas, ya que la API solo será consumida por nuestras propias aplicaciones móviles.

Estoy pensando en elegir una de estas dos opciones:

1. Doorkeeper + Devise: Puedo implementar OAuth 2.0 utilizando Doorkeeper, pero solo usaré la Concesión de credenciales de contraseña, al menos por ahora.
2. ActionController::HttpAuthentication::Token module + Devise de Rails : Esto parece ser la forma más sencilla de hacerlo.

Honestamente, no puedo ver la diferencia entre el método de autenticación de acceso Token y la concesión de credenciales de contraseña de OAuth 2.0 .

¿Cómo uno elegiría uno sobre el otro? ¿Hay alguna otra opción que deba ser considerada?

Answer 1

Si todo lo que tendrá es la "API de propósito único" (solo para aplicaciones móviles), no hay una gran diferencia en términos de seguridad.

Pero si desea extender esta API para que la utilicen los servicios externos, estará en una posición mucho mejor con OAuth 2.0 implementado utilizando Doorkeeper, ya que puede configurar fácilmente, por ejemplo, una concesión de código de autorización para ellos. Por lo tanto, diría que la opción "Portero + Deviso" es más a prueba de futuro, ya que proporciona más opciones, mientras que la autenticación del token HTTP es mucho más simple para la implementación.

Answer 2

Los dos son conceptualmente diferentes cosas:

• "Autenticación de acceso a tokens" especifica un protocolo que describe cómo debe presentarse un token (posiblemente de larga duración) al servidor de forma segura. No dice nada de dónde vino el token o cómo debe interpretarse.
• La "Subvención de credenciales de contraseña" es una parte del flujo OAuth completo, que describe los medios para obtener un token (generalmente de corta duración) .

En cierto sentido, puede usar la Subvención de credenciales de contraseña para obtener un token usando OAuth y luego usar este token en el encabezado de autorización del Token para obtener acceso.

La pregunta entonces es: ¿es útil hacer el viaje de ida y vuelta para intercambiar las credenciales (permanentes y secretas) por un token (temporal), cuando podríamos usar el token (permanente y secreto) almacenado en la aplicación para autorizar inmediatamente de todos modos?

Como lo veo, hay dos beneficios potenciales de usar el flujo completo de OAuth. En primer lugar, le permite agregar otros medios de autorización para terceros de forma natural. En segundo lugar, le permite revocar el token en cualquier momento y forzar una nueva autorización utilizando estos otros medios (si los implementa, por supuesto) sin tener que inventar ninguna rueda.

Por otro lado, siempre puede agregar cualquier parte adicional de "generación de tokens" más adelante, cuando sean necesarios. Por lo tanto, si su plan actual es codificar las credenciales en código de todos modos, sospecho que probablemente sea mejor que confíe en la autorización Token .

No solo es una solicitud más corta, sino que también puede ser ligeramente más segura que la autenticación de Bearer utilizada en OAuth: si un atacante olfatea un token de Bearer , (normalmente) obtendría acceso token completo al servidor hasta su caducidad. No es el caso con tokens Token (normalmente). No es que todo importe demasiado, por supuesto, si el atacante pudiera extraer el secreto compartido de tu aplicación de todos modos.