Diseño de autenticación DRY API entre servicios

3

Estoy creando un servicio de API que requerirá autenticación. Esta será la primera parte de un proyecto que incluirá un servicio de front-end para mi sitio web, y también abrirá el api para el cliente de front-ends de terceros.

He estado planeando cómo voy a dividir mi sitio en el backend / frontend y creo que he encontrado una solución donde no tengo que tener tablas de usuarios duplicadas, pero quería ver si había alguna haciendo agujeros en mi lógica haciendo una pregunta aquí.

El sistema de autenticación está diseñado para ser similar al sistema de autenticación Amazon AWS S3 - asignando a cada usuario una clave y un secreto, y luego usar el secreto para firmar las solicitudes de API de los clientes front-end. Luego, la api busca al usuario desde la api_key, verifica que se firmó con la api_secret del usuario y va desde allí.

El mayor obstáculo es que quiero que mi modelo de usuario viva en el frente. Esto se debe a los vínculos existentes entre el usuario, los modelos de suscripción y la información de pago que realmente no tienen lugar en el servicio API. Para trabajar con esto, cuando la API necesita buscar un usuario api_secret, tiene que comunicarse con mi aplicación de front-end (a través de una línea https segura y un subproceso diferente) para obtenerla. Esta imagen ayudará a explicar eso en el paso 4.

Creo que esto proporcionará un sistema de autenticación seguro para la API, y una manera para que cualquier cliente de aplicaciones para el usuario o un cliente de terceros implemente los pasos 1 y 2, sin duplicar ningún dato de usuario en el servidor. El paso 4 aún siempre llamará a mi aplicación de front-end específica que contiene todas las tablas de usuarios.

¿Es esta una forma tonta de hacer esto?

    
pregunta coneybeare 31.01.2012 - 00:17
fuente

1 respuesta

1

¿A quién estás tratando de proteger? ¿el usuario? ¿La web de front-end? o la API?

Veo un problema porque el secreto de la API se almacena en el front-end, que es más probable que esté expuesto al mundo exterior. Si el front-end está comprometido, entonces cualquiera puede acceder al backend suplantando al usuario. Es un punto probable de intercepción para obtener acceso a esos secretos, de lo contrario solo lo conocen dos partes.

No estoy seguro de haber entendido el punto del usuario que proporcionó el secreto de la API, o si estaba almacenado en el front-end, y el acceso fue otorgado por ejemplo. un nombre de usuario / contraseña.

De lo contrario, parece que puede beneficiarse del uso de OAUTH para firmar solicitudes. OAUTH tiene un modo de dos patas (aunque parezca poco conocido), donde puedes intercambiar fácilmente mensajes firmados entre dos entidades con una clave compartida.

Todo y todo, parece un diseño confuso / confuso, o tal vez es difícil de explicar sin dar más contexto. El mejor consejo es tratar de no reinventar la rueda y usar los algoritmos / soluciones / arquitecturas existentes tanto como sea posible.

    
respondido por el Yoav Aner 01.02.2012 - 22:59
fuente

Lea otras preguntas en las etiquetas