Estoy investigando el uso de Social Login para un servicio web con portales web y aplicaciones móviles. La idea es "Autenticar" al usuario y dejar que el servicio cree una "Clave de API" una vez que el usuario haya sido Autenticado.
Estoy mirando a OpenID / OpenID connect / OAuth 2.
El último párrafo de sección 10.16 de RFC6749 indica:
La autenticación de los propietarios de recursos a los clientes está fuera del alcance de esto especificación. Cualquier especificación que utilice el proceso de autorización. como una forma de autenticación de usuario final delegada al cliente (por ejemplo, servicio de inicio de sesión de terceros) NO DEBE utilizar el flujo implícito sin mecanismos de seguridad adicionales que permitirían al cliente determinar si el token de acceso se emitió para su uso (por ejemplo, restringir la audiencia el token de acceso).
Y Google afirma que para evitar el llamado Problema Confused Adjuty, debe validar los tokens de Access. Consiste en verificar que la audiencia deseada coincida con su propia ID de cliente.
El problema que veo es que una aplicación o persona maliciosa aún puede recopilar el ID de cliente y usarlo en un cliente público malicioso para obtener tokens de acceso que "desprotegen" para su cliente.
Facebook le permite Habilitar una opción para requerir appsecret_proof y dice:
Los tokens de acceso son portátiles. Es posible tomar un token de acceso. generado en un cliente por el SDK de Facebook, envíelo a un servidor y luego hacer llamadas desde ese servidor en nombre de la persona. Un token de acceso También puede ser robado por un software malicioso en la computadora de una persona o El hombre en el ataque medio. Entonces ese token de acceso puede ser usado desde un Un sistema completamente diferente que no es el cliente y no su servidor, generando spam o robando datos.
Puedes evitar esto agregando el parámetro appsecret_proof a cada La API llama desde un servidor y habilita la configuración para requerir pruebas en Todas las llamadas. Esto evita que los malos hagan llamadas API con tu Acceder a los tokens desde sus servidores. Si estás usando el PHP oficial SDK, el parámetro appsecret_proof se agrega automáticamente.
Este enfoque no parece ser mejor: un cliente público malintencionado (después de haber obtenido y usando su ID de cliente legítima) aún puede realizar el proceso de inicio de sesión y luego cosechar el token de acceso portátil para enviarlo a su servicio web (cliente seguro), que incluiría el parámetro appsecret_proof.
¿O me estoy perdiendo algo? ¿Debo renunciar a OAuth2 / OpenID Connect?