Resumen

  • OpenID Authentication 2.0 distinguía el identificador que una persona reclamaba como propio de su nombre local dentro del proveedor de autenticación. Una URL controlada por el usuario podía conservarse al cambiar de proveedor.
  • El sitio de destino debía descubrir el proveedor desde esa URL, cotejar la respuesta con los datos descubiertos y usar el identificador reclamado como clave de la cuenta local. La norma describe la ruta; los archivos citados no contienen un censo de migraciones reales.

Una dirección web podía ser más duradera que la empresa encargada de comprobar una contraseña. La especificación final de OpenID Authentication 2.0 ofrecía a una persona la posibilidad de presentar una URL como su identificador. El sitio donde quería entrar seguía las instrucciones publicadas en esa dirección para localizar al proveedor de autenticación. El navegador acudía al proveedor; el sitio de destino comprobaba la respuesta. La OpenID Foundation anunció el texto final el 5 de diciembre de 2007 junto con otra especificación para intercambiar atributos. La apuesta central del protocolo de autenticación era mantener separado el nombre estable del servicio que verificaba el acceso.

El vocabulario de la norma impedía confundirlos. El Claimed Identifier era el identificador cuyo control afirmaba el usuario. El OP-Local Identifier era un nombre dentro del proveedor y podía estar fuera del control del usuario. Si el sitio receptor archivaba su cuenta con este segundo nombre, una mudanza de proveedor podía parecerle un cambio de persona. La continuidad exigía que el nombre registrado por el sitio siguiera siendo el primero.

La llamada «descubierta» podía hacerse desde el propio HTML de la URL reclamada. En la cabecera de esa página, un enlace rel="openid2.provider" indicaba el punto de servicio del proveedor. Otro enlace, opcional, rel="openid2.local_id" identificaba al usuario dentro de él. El servidor de la página y el servidor del proveedor podían ser distintos. El dueño de la URL podía cambiar el destino del primer enlace sin pedir a cada sitio receptor que renombrara su cuenta.

Había un trabajo de seguridad detrás de esa comodidad. El sitio receptor debía comprobar que el identificador incluido en una respuesta correspondía a un proveedor descubierto desde la URL y que los datos de la respuesta coincidían con los datos descubiertos. Si todavía no había hecho la consulta, debía hacerla al recibir la respuesta. Así se establecía quién estaba autorizado a hablar en nombre de una dirección. Aceptar la palabra de cualquier proveedor sobre cualquier URL habría convertido la portabilidad en una suplantación fácil.

La especificación también decía qué debía recordarse. Recomendaba usar el identificador reclamado como clave de los datos locales del usuario. El modo compatible con OpenID 1.1 planteaba una dificultad adicional: sus respuestas no incluían openid.claimed_id. Cuando el nombre reclamado y el nombre local del proveedor eran distintos, el sitio tenía que conservar el primero durante el intercambio, por ejemplo en la sesión, para abrir después la cuenta correcta.

OpenID se declaraba descentralizado: ninguna autoridad central tenía que registrar o aprobar a proveedores y sitios receptores. El usuario podía conservar su identificador al cambiar de proveedor. Esa propiedad dependía de tres decisiones operativas: mantener bajo control la URL reclamada, publicar allí el proveedor vigente y hallar sitios que verificaran esa delegación y archivaran la cuenta bajo la URL. La norma no ofrece cifras de adopción ni pruebas de que cada implementación resolviera bien la mudanza.

La historia está en el reparto de funciones. El proveedor de acceso podía cambiar sin llevarse por fuerza el nombre con el que otros reconocían al usuario. A cambio, el sitio receptor asumía la responsabilidad de seguir el enlace correcto y guardar la identidad adecuada. OpenID dibujó una salida del encierro en una sola empresa; la salida dependía de que el libro de cuentas de cada sitio estuviera bien escrito.

Documentos originales