Característica de OAuth2, microservicios y "mantenerme conectado"

0

Estoy tratando de aprender más sobre la autenticación en microservicios utilizando OAuth2.

He estado leyendo sobre OAuth2, y si bien entiendo lo básico, tengo muchas dificultades para entender cómo funciona todo junto.

Empecemos con un ejemplo:

Tengo un sitio web, que se basa en dos microservicios:

  • servicio de autenticación: básicamente un servicio auth2 que utiliza la autenticación de contraseña basada en el propietario del recurso.
  • álbum: una vez que un usuario se autentica, puede crear álbumes de fotos y compartirlos con otros usuarios del sitio.
  • el sitio web tiene una opción de "recordarme por 30 días" durante el inicio de sesión.
  • el usuario debe poder ver desde qué dispositivos y ubicaciones ha iniciado sesión y poder finalizarlos (en caso de inicios de sesión no autorizados). Esto es similar a la funcionalidad que proporcionan FaceBook y DropBox.

Comencemos con la aplicación de autenticación, una respuesta auth2 típica se ve así:

{"refresh_token": "aEMpqJsg6aotX9HaeVnFqqRBaQn7Bo", "access_token": "aSAX21mzmYRnizwhn1ltFZWDsIbif4", "expires_in": 36000, "token_type": "Bearer", "scope": "read write"}

El botón de inicio de sesión de mi sitio web solo solicita un servicio OAuth2 a mi servicio de autenticación y recibe la respuesta anterior. Ahora, ¿qué hago con esta información para usar esto? ¿Acabo de almacenar esta respuesta JSON en una cookie? Necesito algún tipo de persistencia para poder usar este token para solicitudes posteriores.

Siguiente pregunta: ¿Puedo crear un token que caduque en 30 días o se considera una mala práctica? Si es así, ¿cómo puedo mitigar esto sin perder esta funcionalidad?

Ahora a la siguiente parte: el servicio de mi álbum necesita saber quién es el usuario. ¿Supongo que la puerta de enlace de la API tiene la responsabilidad de asegurarse de que el token sea correcto, y también incluir el ID de usuario en la solicitud? ¿Qué pasa si el álbum necesita información adicional sobre el usuario? ¿Debería contactarse con la aplicación de autenticación para esto?

Traté de encontrar las respuestas a estas preguntas por mi cuenta, pero es muy difícil encontrar información realmente buena sobre esto. La mayoría de las cosas que encontré en la red me dieron respuestas vagas, como "leer las especificaciones de oauth2" o "usar JWT". Si bien me doy cuenta de que es necesario un buen entendimiento de oauth2, sería útil para mí si recibiera alguna explicación de alguien que tenga experiencia real en la construcción de algo como esto. (Las recomendaciones de libros también son bienvenidas).

    
pregunta Jeroen Jacobs 30.07.2016 - 23:43
fuente

2 respuestas

1

En primer lugar, determine si sus servicios son confidenciales o no.

  

Clientes capaces de mantener la confidencialidad de sus clientes.         credenciales (por ejemplo, cliente implementado en un servidor seguro con         acceso restringido a las credenciales del cliente), o capaz de asegurar         autenticación del cliente por otros medios.

Por lo tanto, por ejemplo, la Aplicación Angular o la Aplicación Móvil generalmente no son confidenciales, pero los servicios de backend son.

Si su servicio es confidencial , puede almacenar de forma segura el token de actualización durante bastante tiempo (como 30 días). El flujo completo sería:

  1. Registrar un cliente en el servidor de Autorización
  2. Almacene de forma segura client_id y client_secret en su servicio

Después de eso, puede autenticar a los usuarios:

  1. autenticar a un usuario
  2. Obtener acceso y actualizar tokens
  3. Almacenar el token de actualización de forma segura
  4. Cuando caduque accesstoken, obtenga uno nuevo con token de actualización

En ese caso, tienes tokens de acceso de corta duración y tokens de actualización de larga duración .

Los tokens de acceso que son válidos durante 30 días son una mala práctica, generalmente se emiten no más de 8 a 12 horas.

Si su servicio no es confidencial , puede pensar en utilizar algún servicio perimetral o un proxy inverso que maneje los problemas de almacenamiento seguro.

Con respecto a obtener acceso a la información del usuario , recomendaré utilizar OpenID Connect que en realidad es más adecuado para fines de autenticación. OpenID Connect es un protocolo de autenticación construido sobre OAuth2. Simplificado, agrega la API de identidad de usuario a OAuth.

OpenID Connect agrega un token adicional a la respuesta del Servidor de autorización (JWT ID Token) con información mínima del usuario y punto final / userinfo especificado donde el servicio puede obtener información adicional del usuario .

Para resumir las recomendaciones:

  1. Use OpenID Connect para la autenticación
  2. Utilice OAuth para las comunicaciones de servicio a servicio
  3. Almacene de forma segura las credenciales del cliente y actualice los tokens
  4. Use tokens de acceso de corta duración y tokens de actualización de larga duración
respondido por el Salamander 04.08.2016 - 23:19
fuente
-1

Realmente me gusta JWT sobre OAuth2 porque JWT está diseñado para autenticación y autorización. OAuth2 es solo Autorización.

Ignorando eso, los dos típicos se pasan a los servicios de la misma manera usando encabezados, por ejemplo:

POST https://your.website.com/api HTTP/1.1
//Other Header informaiton
Authorization: Bearer <Token>

El servidor leerá el token y lo comparará con lo que tiene en el archivo y permitirá / denegará en función de eso. Si necesita más información sobre la arquitectura de un servicio web seguro, sugeriría un Programmers.SE, para preguntas de codificación específicas, Stackoveflow.SE.

Editar: te responde otras preguntas.

Normalmente, los tokens se almacenan en las cookies con la marca de seguridad (solo HTTPS), pero aún así debes tener cuidado con cosas como CSRF.

Sugiero leer en enlace . El equipo de stormpath tiene una gran cantidad de información útil sobre todas sus preguntas, e incluso videos de youtube que ofrecen más discusiones y demostraciones en profundidad. Nunca he usado sus servicios, pero aprendí mucho de ellos. Se centran principalmente en JWT, pero también discuten y trabajan con OAuth2.

    
respondido por el Shane Andrie 05.08.2016 - 00:12
fuente

Lea otras preguntas en las etiquetas