Cómo incorporar el hombre en el medio

0

Estoy diseñando un back-end basado en web para un servicio en línea. El servicio podría soportar portales basados en web y aplicaciones móviles como front-end.

Pero estoy atascado en la forma de admitir sitios web de terceros, es decir, que no sean de confianza, como front-end. De hecho, el mismo problema existe con las aplicaciones móviles, aunque tal vez en menor grado.

Brevemente, el problema es que la autenticación y la autorización deben ocurrir en el back-end, y la pregunta es cómo garantizar que un portal de nivel medio o web no guarde las credenciales secretas de un usuario o que a través de otros medios pueda plantearse como un usuario final y realice operaciones que el usuario no está solicitando!

Necesito poder autenticar al usuario final en el back-end y actualmente tengo una prueba de concepto, y los procesos de registro y autenticación para esto son los siguientes:

  1. El nuevo usuario se conecta a la página de registro público.
  2. ¿Quizás Incluir JS para generar un par de claves pública / privada?
  3. Autorice el acceso al proveedor de Oauth para obtener información básica del perfil.
  4. Recupere los detalles del usuario y rellene el perfil.
  5. El usuario proporciona información adicional (por ejemplo, número de contacto, dirección de correo electrónico de recuperación) y su clave pública para completar el proceso de registro.

Y luego el proceso de autenticación para un usuario que regresa sería algo como:

  1. La aplicación de usuario (Android o Javascript) crea una solicitud con formato JSON.
  2. Solicitud de signos de aplicación con clave privada del usuario.
  3. La aplicación adjunta la Identificación del usuario (user-id / open-id / etc) a la solicitud.
  4. La aplicación publica la solicitud en la API (back-end).
  5. API comprueba que la solicitud esté autenticada para el usuario especificado (verifica la firma)
  6. API comprueba que las solicitudes están autorizadas.
  7. La API procesa la solicitud y genera la respuesta.
  8. La API encripta la respuesta usando la clave pública del usuario.
  9. la API adjunta información básica (por ejemplo, la versión de la API y el identificador de solicitud) a la respuesta.
  10. La API devuelve la respuesta en la sesión HTTPS del usuario.

Por lo que puedo decir, el problema viene en el paso 4. La Aplicación podría enviar la solicitud a cualquier lugar, por ejemplo, un sitio web de terceros que agregue beneficios como el formato y las funciones avanzadas. Pero esto significa que el nivel intermedio enviará múltiples consultas al back-end en nombre del usuario final, generará la respuesta y devolverá esa página o informe al usuario.

Por cierto, espero aprovechar dos beneficios específicos del uso de openid / oauth (que aún no he trabajado en mi implementación de prueba de concepto)

a. Facilite el proceso de registro: el usuario no necesita recordar     una nueva contraseña y no necesita completar todos sus detalles, solo     los bits que necesita la aplicación que no son suministrados por Google+ y     amigos.

b. No necesito tratar con contraseñas olvidadas / reinicios de contraseña en     99% de los casos. Mientras el usuario tenga acceso a su ID abierta     Cuenta que pueden recuperar el acceso al servicio. Cuando se conecta desde     un nuevo dispositivo, por ejemplo, un segundo PC / tableta / lo que sea, la aplicación     crea un nuevo par de claves públicas / privadas y la parte del proveedor de openid     Da acceso al perfil del usuario. Si el usuario cambia a un nuevo     proveedor de OpenID puede utilizar la dirección de correo electrónico de recuperación para vincular un nuevo     Openid URI a su perfil en el sistema.

Por otra parte, no estoy buscando integrarme con otras características más avanzadas de los proveedores de openid en esta etapa. Realmente solo quiero que un tercero se encargue de la tarea de identificar a los usuarios y administrar sus contraseñas.

El problema es que el usuario se registra en el back-end a través de una interfaz en la que no se puede confiar. Un mal nivel intermedio puede potencialmente sustituir la clave pública de un usuario por una clave pública para la cual controlan la clave privada. ¿Cómo diseño para este tipo de situación? No permito las interfaces de terceros al back-end (preferiría no participar en las aplicaciones y los sitios web, aunque implementaré una aplicación de referencia)

    
pregunta Johan 19.01.2015 - 10:28
fuente

1 respuesta

2

Esto es para lo que oAuth es. oAuth permite que una solicitud de servicio de terceros realice ciertas operaciones en nombre de un usuario con el consentimiento de los usuarios, por ejemplo, acceso de lectura a los contactos de los usuarios. El tercero recibe un token que le permite realizar estas acciones y es responsabilidad del back-end validar el token y las acciones que se le permite realizar. El token puede tener un límite de tiempo y, por lo tanto, incluso si el tercero mantiene el token, se vuelve inútil después de que haya caducado.

    
respondido por el aviv 19.01.2015 - 15:08
fuente

Lea otras preguntas en las etiquetas