Almacenar la información necesaria de OpenID

Question

Estoy tratando de implementar la autenticación OpenID para mi sitio. Este es el escenario:
Quiero que el usuario sea capaz de

• inicio de sesión utilizando sólo OpenID (. Usuario puede simplemente ponerse verificado visitando proveedor de OpenID hay necesidad de crear una cuenta personalizada con el correo electrónico, contraseña),
• A través del correo electrónico/contraseña (el usuario se ha registrado en el sitio al completar un formulario)
• Adjunte identificación (es) abierta (s) a sus cuentas (cuentas abiertas + correo electrónico para una cuenta).

Ahora no sé qué credenciales debo almacenar para la identificación abierta. y no estoy seguro sobre el esquema DB. Aquí está el esquema de base de datos:

Table: Users 
UserId => PK 
... => Custom info. Not related to authentication. 

Table: Authentication 
AuthenticationId => PK 
LoginId => (when custom site membership => email address) (when openId => openid unique address) 

UserId => FK to Users. 
Provider =>(when custom site membership => "CUSTOM") (when openId => openid provider address) 
Password => filled when using custom membership. empty when using open id. 

Ahora, cuando un usuario inicia una sesión, ya sea mediante el uso de miembros openid/encargo, acabo de mirar a la mesa de autenticación y busco credenciales y obtener el usuario correspondiente. Si no hay usuarios, creo un nuevo usuario y agrego una entrada en la tabla de autenticación.

• La pregunta principal: ¿Es almacenando Provider y LoginId (ver los comentarios anteriores para ver lo que se almacena en estos campos) suficientes para almacenar la autenticación OpenID? ¿Debo almacenar datos adicionales para que cuando el usuario regrese pueda autenticarlo en base a mis datos guardados?

• ¿Sugiere algún otro enfoque (más eficiente) para implementar esto?
  Gracias.

Answer 1

tienda del ClaimedIdentifier para el usuario openid - no la dirección del proveedor. El identificador reivindicado es lo que el protocolo OpenID verifica que es exclusivo para el usuario y también potencialmente brinda portabilidad a través de los proveedores de OpenID. Además, dado que OpenID Connect (un sucesor inconcluso de OpenID 2.0) puede dejar en desuso los Identificadores Reclamados de OpenID 2.0, también le conviene registrar el URI del Endpoint del Proveedor de OpenID y la dirección de correo electrónico afirmada por el Proveedor en el registro del usuario. Por ahora, haz no utilízalos como parte de tu flujo de autenticación, pero al registrarlos, podrás luego determinar qué direcciones de correo electrónico 'confías' (es decir, si decides que las direcciones de correo electrónico afirmadas por Google son confiables) y Permitir al usuario migrar su cuenta a una conexión OpenID Connect utilizando esa dirección de correo electrónico verificada. Esto también mitigará el peligro de que el Reino de su sitio web (generalmente http://yourdomainname.com) cambie y cause que todos los identificadores de reclamos de sus usuarios de Google cambien, lo que solo puede ser realmente recuperado a través de su dirección de correo electrónico, trágicamente.

También recomiendo usar diferentes tablas para los diferentes tipos de autenticación. Hay un par de ventajas aquí. El más importante es que desde el punto de vista arquitectónico hace que sea más difícil introducir un agujero de seguridad en su sitio web que podría permitirle a alguien ingresar (por ejemplo) un OpenID en el campo de nombre de usuario y una contraseña en blanco y hacer que aparezca como un coincidencia de base de datos e inicio de sesión sin que ocurra ninguna autenticación real. En segundo lugar, proporciona un modelo más flexible en caso de que desee agregar un tercer mecanismo de autenticación en lugar de hacer que su tabla de 'Autenticación' crezca horizontalmente para todos los usuarios. Por ejemplo, OAuth 2.0 y "OpenID Connect" probablemente introduzcan nuevos tipos de autenticación en su sitio cuando agregue soporte para ellos a lo largo de los años, y la adición de nuevas tablas para manejar los nuevos tipos de datos parece encajar mejor.

Answer 2

Acabamos de guardar la URL de OpenID reclamo. Es posible que desee solicitar información adicional del proveedor, como el nombre del usuario. Lo más importante es separar la membresía y la autenticación.

Nuestro esquema era

Profiles 
-------- 
UserId 
FirstName 
LastName 
etc. 

Users 
----- 
Username 
Password 

Profiles.UserId es simplemente una propiedad de cadena que almacena el nombre de usuario, ya sea interna o usuarios de su Solicitar URL de OpenID, dependiendo de cómo se registran.

Al realizar una autenticación exitosa (ya sea usando un nombre de usuario/contraseña interno o un proveedor externo) simplemente configuramos su cookie de autenticación usando su nombre de usuario interno o su URL de reclamo. Obtener el perfil del usuario es solo cuestión de encontrar el generador de perfiles donde (UserId == User.Identity.Name).

Esto tiene la ventaja de que un usuario puede elegir cambiar la forma en que se autentica en cualquier punto (tal vez cambiando a una cuenta interna o usando un proveedor diferente).