OAuth para Autenticación / Autorización Multipartita

Navega tus respuestas
3

Trabajo para una empresa web que está realizando una reescritura masiva para separar nuestros datos en su propia aplicación de servicio RESTful: el objetivo es poder vender el acceso a terceros y crear prototipos rápidamente de aplicaciones internas sin necesidad de acceso directo a la base de datos.

Actualmente tenemos tres aplicaciones: la API de datos antes mencionada, un CMS y un front-end. Los usuarios deben poder iniciar sesión en el CMS para modificar los datos a través de la API, y realmente nos gustaría integrar nuestras aplicaciones web de Google en esto: iniciar sesión a través de Google. Idealmente, esto usaría el flujo de OAuth, porque es el más transparente para nuestros usuarios, pero no conozco ninguna forma de compartir la información de OAuth entre aplicaciones sin comprometer su seguridad.

Lo que he probado

¿Concretamente? Nada. Mi propuesta inicial fue generar lo que es esencialmente "OAuth anidado": configurar mi aplicación de datos como un proveedor de OAuth para todas las demás aplicaciones, luego usar el flujo de OAuth de Google como el estándar de autenticación no especificado dentro de la capa de datos. Sería bastante transparente para el usuario, pero parece violar el concepto de OAuth, y creo que debería haber una mejor manera de hacerlo. El flujo se vería así:

  1. Inicio de sesión de solicitudes de usuario para el CMS
  2. CMS obtiene un token de autenticación de la capa de datos
  3. CMS redirige la página de inicio de sesión del usuario alojada en la capa de datos
  4. Data Layer obtiene un token de autenticación de Google
  5. Data Layer redirige al usuario a la página de inicio de sesión de Google
  6. Google autentica al usuario, luego lo redirige a la capa de datos con un token de autenticación
  7. Data Layer usa el token de autenticación para obtener el token de acceso para los servicios de Google
  8. La capa de datos redirige al usuario al CMS con otro token de autenticación
  9. Auth Layer usa el token de autenticación para obtener un token de acceso para los servicios de datos

Pero parece, bueno, torpe. También me gustaría no tener que forzar al usuario a través de varias páginas "Permitir": una de Google para permitir la capa de datos y una de la capa de datos para permitir el acceso al CMS (o alguna aplicación posterior). Lo que realmente necesito es usar Google para una situación de SSO o Kerberos, y hacer que Google dé boletos para mis aplicaciones. Si alguien sabe una forma de aprovechar eso con Google, con mucho gusto destruiría todo este diseño.

    
pregunta FrankieTheKneeMan 08.11.2013 - 21:41
fuente

2 respuestas

1

Después de mucha investigación, descubrí que Google tiene un verificador de token de acceso no protegido - enlace que se puede utilizar para verificar

  1. a qué aplicación se emitió el token
  2. En qué dirección de correo electrónico se emitió el token en nombre de.

Al realizar un seguimiento del Identificador de Google de la aplicación, la capa de datos puede aceptar un token de acceso y verificarlo para autenticar al usuario y la aplicación, con un poco de ayuda de un esquema de firma de API estándar que involucra un secreto conocido solo por la capa de datos. y la aplicación de acceso. Esto no requiere confianza, ya que cada aplicación que necesita información de la capa de datos puede registrarse con Google oAuth, y sin el secreto compartido entre ellos, la API de datos no puede usar el token de acceso en nombre de los usuarios. Esto impide que la capa de datos acceda a las API de Google en nombre del usuario, pero se puede implementar una oAuth específica para la API de datos para obtener acceso a los recursos del usuario.

    
respondido por el FrankieTheKneeMan 12.11.2013 - 18:43
fuente
0

Creo que la solución que propones es la mejor que vas a encontrar.

Permite recapitular su problema para verificar que entiendo correctamente. Tiene una "Capa de datos" que almacena datos que son propiedad de los usuarios. Los usuarios se autentican utilizando el punto final OAuth de Google. También tiene una serie de aplicaciones "front-end" que pueden acceder a la capa de datos, pero no son de confianza implícita. El comportamiento que desea es que si el usuario A aprueba la "aplicación front-end A", esa aplicación puede acceder a los datos que pertenecen al usuario A en la capa de datos, pero no a los datos que pertenecen a otros usuarios.

Para admitir este diseño, cada usuario tendrá que aprobar explícitamente cada aplicación de front-end que use, aunque solo tendrá que hacerlo una vez. Esto es inherente al diseño. La pregunta es si los usuarios se autentican en aplicaciones front-end usando Google directamente o usando un proveedor OAuth en la capa de datos.

Si usaban Google directamente, entonces la aplicación de front-end conocería la identidad del usuario. Sin embargo, la aplicación de aplicaciones para usuario no podría demostrar de manera segura a la capa de datos que conocía la identidad del usuario. OAuth no apoya esto, y hay una buena razón. En esta configuración, ¿en qué momento acepta el usuario permitir que la "aplicación de aplicaciones de usuario A" acceda a la capa de datos? Su capa de datos no tiene capacidad para agregar una capacidad al punto final OAuth de Google.

Con la configuración de "OAuth anidada" que sugieres, el usuario ve ese mensaje. Y cuando lo aprueban, la aplicación de front-end puede demostrar de manera segura a la capa de datos que el usuario ha aprobado la aplicación.

Entre el front-end y la capa de datos, está utilizando OAuth como se pretendía originalmente, otorgándole a las aplicaciones externas algunos privilegios para sus datos en un sitio web. Entre la capa de datos y Google, está utilizando OAuth para la autenticación, que es un caso de uso ligeramente diferente.

Por cierto, mencionas Kerberos, pero esto tiene exactamente el mismo problema. En un entorno Kerberos, puede identificarse ante el servidor de correo y el servidor de archivos, pero el servidor de correo no puede autenticarse ante el servidor de archivos en su nombre.

    
respondido por el paj28 11.11.2013 - 18:42
fuente

Lea otras preguntas en las etiquetas

¿Es seguro eliminar estos grupos del área de la Política de seguridad local? ¿Cómo interceptar la url para no permitir la navegación forzada en un proyecto web dinámico simple?