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?