¿Dónde debería ir la lógica de autorización en una aplicación basada en API?

Question

¿Dónde debería ir la lógica de autorización en una aplicación basada en API?

Navega tus respuestas

#1 de Xiong Chiamiov (2 votos)

0

Tengo una nueva aplicación basada en la API de Rails, donde necesito implementar la autorización.

Arquitectura general:

React frontend -> Rails API layer -> Rails model/server layer

Al explorar diferentes enfoques, tengo una confusión.

¿Deberíamos poner la lógica de autorización en la capa API o la capa de servicio?
Enfoque de la capa API: Desarrollaremos un middleware de autorización que se ubicará entre nuestra interfaz y la capa API, y todas nuestras llamadas a la API se enrutarán a través del middleware de autorización para verificar si el usuario tiene permiso para llamar a ese parituclar. api.
Capa de servicio: toda la verificación de autorización irá a la capa de servicio y tendremos que verificar antes de cada operación de db si el usuario tiene permiso para hacerlo. (Utilizando cancancan / pundit ) y si el usuario no tiene permiso, envíe el mensaje de error a la capa API.

Sería de gran ayuda si alguien pudiera sugerir en función de su experiencia.

authentication authorization api rails

pregunta Deepak Kumar Padhy 07.06.2017 - 05:36

fuente

1 respuesta

Lea otras preguntas en las etiquetas authentication authorization api rails

¿Busca un tipo de virus específico? Descifrar datos con texto conocido

score 2 · Answer 1

Obviamente, la autorización debe verificarse en el lado del servidor, ya que confiar únicamente en las verificaciones de clientes lo abre a clientes maliciosos. No existe un consenso general sobre en qué parte del código del servidor debe hacer estas comprobaciones, pero voy a argumentar que sea lo más cerca posible del borde.

Por un lado, esto es a menudo lo más fácil. Usted tiene acceso inmediato a los datos de la llamada y puede devolver el mensaje de error apropiado directamente en lugar de confiar en una excepción que rebosa en varias capas.

En segundo lugar, la autorización suele ser más compleja de lo que podría anticipar. Tome GitHub, por ejemplo, para realizar ciertas acciones confidenciales, primero debe volver a ingresar su contraseña. Este tipo de verificación tiende a ser mucho más fácil de manejar página por página, en lugar de construir condicionales complejos en la capa modelo.

Desde una perspectiva de seguridad, definitivamente hay un argumento para un enfoque de autorización profunda, a saber, que no confíe en que los desarrolladores recuerden manejar la autorización en cada nuevo punto final. Sin embargo, mi opinión es que la claridad y la simplicidad que se obtiene con un enfoque basado en el borde superan estos beneficios.