Usando OpenID como el único método de autenticación

Question

He leído las otras preguntas y sobre todo hablan de la seguridad de hacerlo. Eso no es completamente mi preocupación, principalmente porque el sitio web es cuestión es un juego basado en navegador. Sin embargo, el problema más grande es el usuario: no todos los usuarios saben leer y escribir lo suficiente como para comprender OpenID. Claro, RPX lo hace bastante fácil, que es lo que usaré, pero ¿y si el usuario no tiene una cuenta en Google o Facebook o lo que sea, o no confía en que el sistema inicie sesión con una cuenta existente? Tendrían que obtener una cuenta en otro proveedor; estoy seguro de que la mayoría sabrá cómo hacerlo, y mucho menos se molestará en hacerlo.

También existe el problema de cómo administrarlo en la aplicación. Un usuario puede querer usar múltiples identidades con una sola cuenta, por lo que no es tan simple como el nombre de usuario + contraseña para tratar. ¿Cómo almaceno las identidades OpenID de un usuario en la base de datos? El uso de OpenID también me da una ventaja: RPX puede proporcionar una amplia información de perfil, por lo que puedo rellenar el formulario de perfil y pedirle al usuario que lo edite según sea necesario.

Actualmente tengo esto:

Users: 
------ 

ID  Email    Etc. 
--  --------------- ---- 
0  bob@yahoo.com  ... 
1  alice@yahoo.com ... 

UserOpenIDs: 
------------ 

ID  UserID  OpenID 
--  ------  ------ 
0  0   0 
1  0   2 
2  1   1 

OpenIDs: 
-------- 

ID  Provider Identifier 
--  -------- ---------------- 
0  Yahoo  https:\\me.yahoo.com\bob#d36bd 
1  Yahoo  https:\\me.yahoo.com\alice#c19fd 
2  Yahoo  https:\\me.yahoo.com\bigbobby#x75af 

Con estas claves externas:

UserOpenIDs.UserID -> Users.ID 
UserOpenIDs.OpenID -> OpenIDs.ID 

es que la manera correcta de almacenar identificadores OpenID en la base de datos? ¿Cómo coincidiría con el identificador que RPX me dio con uno en la base de datos para iniciar sesión en el usuario (si se conoce el identificador).

Así que aquí están las preguntas concretas:

• ¿cómo iba a hacerlo accesible a los usuarios que no tengan un OpenID o no querer usar uno? (preocupaciones de seguridad sobre, por ejemplo, iniciar sesión con su cuenta de Google, por ejemplo)
• ¿Cómo guardo el identificador en la base de datos? (No estoy seguro si las tablas de arriba son correctas)
• ¿Qué medidas debo tomar para evitar que alguien inicie sesión como otro usuario y felizmente haciendo algo con su cuenta? (como entiendo, RPX envía el identificador a través de HTTP, entonces lo que cualquiera debería hacer es agarrarlo y luego ingresarlo en el campo "OpenID")
• ¿Qué más debo tener en cuenta cuando uso OpenID?

Answer 1

haciéndolo accesible

Primera relativas a los usuarios que no tienen un OpenID, se puede hacer una pequeña página que explica cómo crear una cuenta (o incluso apuntan a algunos proveedores). De esta manera, no es realmente más difícil crear una cuenta OpenID que una cuenta normal.

Para las personas que no quieren usar OpenID, tienen dos opciones. El primero: implemente un inicio de sesión antiguo al lado de su inicio de sesión de OpenID y permita que los usuarios elijan el método que desean. El segundo es tener solo OpenID ... esto simplifica su trabajo. Decir que algunos usuarios confían más de un sitio web de un proveedor de OpenID de confianza para conectarse, en mi opinión es bastante extraño como proveedores de OpenID menudo utilizan conexiones cifradas, etc ...

El almacenamiento en la base de datos

El esquema propuesto por johnny g es lo que necesita. (sólo que no sé por qué estás almacenando las direcciones URL con barras invertidas en lugar de barras)

Es posible que desee para normalizar sus URL antes de usarlos para que pueda evitar cosas como http://openid.test.com/abc y http://openid.test.com/abc/ siendo manejado como diferentes URL.

medidas adicionales para tomar

Ninguno. Solo debe usar una biblioteca del http://openid.net/developers/libraries.

La confirmación de la identidad del usuario es un problema del proveedor. Solo el usuario y el sitio web conocen la contraseña de la cuenta.

Si alguien tiene su URL de OpenID (que es público), que aún necesita la contraseña (o cualquier otro tipo de método de autentificación, tales como un certificado SSL) para poder conectarse.

Answer 2

me di cuenta de una respuesta a la primera pregunta: ¿

Si el usuario no pueda o no desee utilizar OpenID, asociarse con un proveedor existente y firmar para arriba directamente en el sitio web, o convertirse en un proveedor mismo (aunque esto también significa tener cuentas clásicas de nombre de usuario y contraseña, y tipo de error en el sentido de la pregunta -> usando solo OpenID).

Answer 3

Arg, respondiendo -fying mi comentario anterior.

A su tercera pregunta "mide ... para evitar que alguien inicie sesión como otro usuario ...", como entiendo OpenId, nunca acepta una URL de OpenId de una fuente que no es de confianza. En la implementación, su sitio alberga el inicio de sesión de un proveedor, el sitio del proveedor se comunica con usted directamente, por lo que acepta una URL de OpenId desde un sitio de confianza, siempre.

En otras palabras, incluso si un usuario malintencionado recopila OpenIds como Pokémon, no tiene ningún medio para acceder a su sistema.

Para su segunda pregunta "¿cómo almaceno ..." su esquema funcionará, aunque parece un poco relajado. Por ejemplo, al usar una asignación de muchos a muchos [es decir, UserID to OpenID], permite que un usuario pertenezca a muchos OpenIds y un único OpenId pertenezca a muchos usuarios. Quieres lo primero sin lo último.

Restricción de clave externa simple será suficiente.

UserID  Email   
------  --------------- 
86000  bob@yahoo.com 
86001  alice@yahoo.com 

UserID  Identifier 
------  ---------------- 
86000  https:\\me.yahoo.com\bob#d36bd 
86000  https:\\me.yahoo.com\bigbobby#x75af 
86001  https:\\me.yahoo.com\alice#c19fd 

Siempre UserID es una clave externa a Users mesa y hay una restricción de clave única en Identifier, esto en esencia: a User posee cero o únicos Identifier s. En principio, probablemente también daría una llave primaria en esa mesa, pero eso es gravy.

Espero que esto ayude :)

PS si tiene dudas acerca de la integración o el aprovechamiento de OpenID, a continuación, paso a través de una aplicación. Identifique cada parte de la fuente que toma una URL de OpenId, luego pregúntese si es posible que un usuario malintencionado acceda a ese punto de entrada. Espero que haya un solo punto de entrada y que sea inaccesible para todos, excepto para los proveedores de OpenId de confianza.