¿Cuáles son las formas más comunes de diseñar el proceso de verificación de los tokens de acceso entre el servidor de autenticación y el recurso utilizando OAUTH 2.0?

2

Estoy tratando de construir una aplicación web dividida en un grupo de microservicios y cada microservicio es un servidor de recursos. También tengo un servidor de autenticación separado.

Me pregunto cuál de los siguientes enfoques es mejor o si cree que tiene una mejor idea o si cree que OAUTH no es la herramienta adecuada para esto.

Estas son las formas en que lo he intentado:

  • El usuario (propietario del recurso) va a la página de inicio de mi aplicación enlace
  • Esta página de destino tiene un campo de nombre de usuario y contraseña, por lo que, una vez que el usuario ingrese en estos campos, realizo una llamada ajax al servidor de autenticación, que finalmente me dará un token de acceso después del FLUJO DE SALIDA DE DOS PUNTOS.
  • Ahora tomo el token de acceso auth y voy al servidor de recursos para acceder al recurso.
  • El servidor de recursos ahora realizará otra llamada http al servidor de autenticación mediante programación para verificar el token de acceso una vez que el servidor de autenticación diga que sí, entonces el servidor de recursos servirá la solicitud hasta su finalización (de esta manera, el servidor de recursos estará totalmente aislado con la autenticación proceso)

La otra forma sería permitir que el servidor de recursos verifique el token de acceso al hablar con la base de datos compartida.

¿Cuál de estos es el más común en la industria? ¿Alguna otra idea sobre cómo verificar los tokens de acceso?

    
pregunta user1870400 16.10.2015 - 22:29
fuente

1 respuesta

1

OAuth2 está diseñado para la autorización de terceros clientes para acceder a recursos protegidos en nombre del propietario de dichos recursos.

  1. No está diseñado para autenticación : mencionas que utilizas autenticación de dos patas en tu flujo, asumo que te refieres a flujo de credenciales del cliente o la Subvención de credenciales de contraseña del propietario del recurso . Ambas son la herramienta equivocada para el trabajo, y como ya tiene las credenciales del usuario, no veo por qué no puede autenticarlas directamente.
  2. No es para la comunicación entre el proveedor de recursos y el servidor de autorización : este aspecto está deliberadamente fuera de alcance en la especificación :

      

    La interacción entre el servidor de autorización y el servidor de recursos   Está más allá del alcance de esta especificación. El servidor de autorizaciones   puede ser el mismo servidor que el servidor de recursos o una entidad separada. UNA   El servidor de autorización individual puede emitir tokens de acceso aceptados por   servidores de recursos múltiples.

Estos parecen ser los dos puntos principales que intentas resolver y ninguno se ajusta al caso de uso de OAuth.

Debe comprender que el objetivo de OAuth es separar los roles del cliente y del usuario. Este no es el problema que estás tratando de resolver.

Comprenda el problema que necesita para resolver y use las herramientas adecuadas para cada trabajo.

Para la autenticación, puede usar OpenID Connect, Kerberos, algunos servicios basados en SAML, o configurar su propia autenticación en una base de datos con contraseñas de hash pkbdf.

Para la autorización, podría haber un lugar para OAuth en su solución, pero podría haber otras opciones que funcionen mejor en ese entorno. No te fijes en la herramienta, enfócate en el problema en cuestión.

    
respondido por el GnP 09.09.2016 - 03:50
fuente

Lea otras preguntas en las etiquetas