web services - protocolos - OAuth 2: separar el servidor de recursos y el servidor de autorizaciones

protocolos de autorizacion

Question

La especificación de OAuth 2 me lleva a creer que el "servidor de recursos" y el "servidor de autorizaciones" no necesariamente tienen que ser la misma aplicación, pero estoy luchando por descubrir cómo esto se implementa realmente en la práctica.

Como ejemplo, supongamos que existen las siguientes aplicaciones:

• servidor de recursos
• servidor de autorizaciones
• frontend web
• aplicación de cliente de terceros

Escenario n.º 1: iniciar sesión en la interfaz web

• el usuario envía el formulario de inicio de sesión
• aplicaciones web POST credenciales para autenticar el servidor (grant_type = contraseña) y recibe un access_token
• la aplicación web almacena access_token en una sesión
• en cada solicitud posterior:
  • OBTENER recurso (s) del servidor de recursos (w / access_token en el encabezado Authorization) y renderizarlo en la interfaz web
  • si obtenemos un 401, entonces el usuario se desconecta (elimina access_token de la sesión)

Escenario n.º 2: Autorización de aplicaciones de terceros

• el usuario solicita autorización del servicio de autenticación
• permitir / negar formulario se muestra
• el usuario se redirige a la aplicación del cliente con el código de autorización presente
• aplicación de cliente código POST para auth service (grant_type = authorization_code) y recibe un access_token
• el cliente obtiene recursos del servidor de recursos que pasa (con el encabezado de autenticación)

La parte que tengo problemas para entender es cómo autenticar al usuario antes de mostrar el formulario permitir / denegar en el escenario n.º 2. El usuario puede iniciar sesión en la aplicación web principal, pero el servicio de autenticación no tiene idea de eso y de alguna manera debería autentificar al usuario nuevamente. ¿El servicio de autenticación también necesita admitir inicio de sesión / sesiones?

Me pregunto si podría tener más sentido que la aplicación web sea responsable de mostrar el formulario de permiso / denegación por dos motivos:

1. mantiene toda la interfaz de usuario en una sola aplicación
2. no obligaría al usuario a volver a enviar sus credenciales si ya han iniciado sesión en la aplicación web

Aquí hay una posible alternativa al escenario n. ° 2:

• el usuario solicita autorización de la aplicación web
• permitir / negar formulario se muestra
• POST de la aplicación web al servidor de autenticación que crea una nueva concesión, se devuelve el código de autorización
• la aplicación web redirige a la aplicación del cliente con el código de autorización presente
• aplicación de cliente código POST para auth service y recibe access_token

¿Cuál es la mejor manera de manejar esto? ¡Cualquier comentario general, consejo, etc. sería increíble!

Gracias

Answer 1

Documentos de OAauth2 framework: https://tools.ietf.org/html/rfc6749

(A) El cliente solicita un token de acceso al autenticarse con el servidor de autorizaciones y presentar un permiso de autorización.

(B) El servidor de autorización autentica al cliente y valida la concesión de autorización, y si es válido, emite un token de acceso y un token de actualización.

(C) El cliente realiza una solicitud de recurso protegido al servidor de recursos presentando el token de acceso.

(D) El servidor de recursos valida el token de acceso y, si es válido, atiende la solicitud.

(E) Los pasos (C) y (D) se repiten hasta que el token de acceso caduque. Si el cliente sabe que el token de acceso ha caducado, se salta al paso (G); de lo contrario, realiza otra solicitud de recurso protegido.

(F) Dado que el token de acceso no es válido, el servidor de recursos devuelve un error de token no válido.

(G) El cliente solicita un nuevo token de acceso autenticándose con el servidor de autorización y presentando el token de actualización. Los requisitos de autenticación del cliente se basan en el tipo de cliente y en las políticas del servidor de autorización.

(H) El servidor de autorización autentica al cliente y valida el token de actualización, y si es válido, emite un token de acceso nuevo (y, opcionalmente, un token de actualización nuevo).

Answer 2

Es probable que su escenario alternativo sea el que desee: si realmente desea separar sus flujos, podría intentar algo como esto:

1. el usuario solicita autorización del servicio de autenticación en nombre del servicio con el código grant_type =
2. El servicio de autenticación se da cuenta de que el usuario no ha iniciado sesión: redirige a la aplicación web con un parámetro de solicitud que solicita al servidor web que devuelva al usuario.
3. parámetro de solicitud de tiendas de aplicaciones web, luego solicita nombre de usuario / contraseña
4. aplicación web POST credenciales para autenticar el servidor (grant_type = contraseña) y recibe un access_token.
5. la aplicación web almacena access_token en una sesión
6. la aplicación web genera un token firmado que captura la identificación del usuario y redirecciona al servicio de autenticación con token firmado como parámetro de solicitud
7. el servicio de autenticación analiza el token firmado, extrae la identificación del usuario, muestra la forma de permitir / denegar
8. el usuario se redirige a la aplicación del cliente con el código de autorización presente
9. aplicación de cliente código POST para auth service (grant_type = authorization_code) y recibe un access_token
10. el cliente obtiene recursos del servidor de recursos que pasa (con el encabezado de autenticación)