¿Puedo deshacerme del almacenamiento de secretos de usuario utilizando OpenID, y qué necesito almacenar?

1

¿Qué información debe mantener sobre un usuario para ser un consumidor de OpenID?

Quiero usar OpenID para permitir a los usuarios registrarse y autenticarse en mi sistema. Así que mientras estoy en eso, no quiero duplicar esfuerzos y eliminar las contraseñas innecesarias, etc., de ser almacenadas.

Supongo que además de los detalles del perfil del usuario, deberá almacenar una copia del token de autenticación / identificación del usuario del proveedor de ID, así como el URI del ID del usuario, y una dirección de correo electrónico de recuperación en caso de que el proveedor de ID no sea accesible o el usuario desea vincular un nuevo proveedor de ID a su cuenta en su sistema. También parece que hay un Token de "solicitud" temporal que se usa durante el registro y / o durante la autenticación, pero es de corta duración y se usa solo una vez, por lo que es posible que no sea necesario almacenarlo en la base de datos alguna vez.

¿Los diferentes proveedores de ID, por ejemplo, Facebook, Twitter, LinkedIn, Google Connect proporcionan tokens de autenticación lo suficientemente similares como para que pueda llamar a las columnas de la base de datos algo como "IDProviderToken" e "IDProviderURI", o necesito datos específicos de Facebook / Google / etc?

    
pregunta Johan 21.01.2015 - 13:19
fuente

2 respuestas

2

Lo que mantienes sobre el usuario es tu propia decisión. La implementación más básica es mantener una ID de usuario (la que se recibió del proveedor de ID abierta) y el token que recibe del proveedor de ID abierta (que incluye el token de acceso, la caducidad y el token de actualización). Todo lo que desees mantener más allá de eso depende de ti.

Por lo que sé, todos los proveedores de openid connect deben responder con la misma estructura de datos ... que forma parte del protocolo, pero openid tiene tres versiones: 1.0, 2.0 y conexión

Algunos ejemplos de proveedores: Google y Microsoft Azure ahora usan openid connect para sus servicios de openid. Yahoo usa openid 2.0 Usted mencionó Facebook: no son un proveedor de OpenID, tienen su propio protocolo único

    
respondido por el aviv 21.01.2015 - 16:27
fuente
0

Al final, decidí no usar ninguna forma de OpenID (ni auth ni ninguno de sus amigos)

En mi proyecto, dependiendo de los proveedores de openID, se introdujo una configuración de seguridad no válida. El principio es que ningún sistema debe depender de otro sistema por seguridad cuando el otro sistema tiene una garantía de nivel de seguridad inferior o desconocida que la requerida por el sistema.

Si bien OpenID en principio es bueno, la implementación se deja a los proveedores y prácticamente no hay garantías.

JWT por sí solo demostró ofrecer lo que se necesitaba: a) Deshágase de almacenar los secretos del usuario utilizando el principio de "Algo que tiene" en lugar del uso común de "Algo que sabe" (en forma de contraseña) como medio de autenticación. Esto demostró tener beneficios adicionales al hacer que el servidor sea "sin estado" y con mayor rendimiento al eliminar las búsquedas en grandes tablas de usuarios. b) Mantener las sesiones del lado del cliente elimina aún más las sesiones mantenidas del lado del servidor. c) Permitir un método para actualizar tokens utilizando un atributo que no está almacenado en el token aumenta la seguridad (por ejemplo, una parte maliciosa necesita tanto el nombre de usuario Y un token válido existente para poder renovar cualquier token).

Aside / FWIW: Cuando hice esta pregunta hace 3 años, muy poco estaba disponible en la web sobre este tema.

    
respondido por el Johan 03.12.2018 - 10:39
fuente

Lea otras preguntas en las etiquetas