Resumen

El proveedor tenía el calendario; el sitio, la cuenta

La noticia de febrero de 2014 celebraba la ratificación de OpenID Connect y daba a los desarrolladores una fecha concreta: el 20 de abril de 2015 acabaría la compatibilidad de Google con OpenID 2.0. La empresa quería concentrar su acceso federado en el protocolo nuevo. Ofrecía herramientas propias para facilitar la transición. El plazo superaba un año, pero era el plazo del proveedor. Los sitios podían preparar sus sistemas; no podían pedirle al antiguo servicio de entrada que siguiera funcionando por su cuenta.

Una cuenta de un sitio no es solo el instante de entrar. Detrás de su identificador puede haber trabajo guardado, compras, preferencias, membresías y permisos. Con OpenID 2.0, el sitio podía usar como clave local un identificador reclamado y verificado. OpenID Connect representa la identidad mediante una pareja distinta: el emisor del token y el sujeto. La misma persona podía presentarse con la nueva pareja y no coincidir automáticamente con la clave antigua. Si el sitio creaba otra cuenta, el usuario encontraría un perfil vacío. Si emparejaba mal los identificadores, una persona podría entrar en un perfil ajeno.

En el aviso del 20 de marzo de 2015, Google volvió a señalar el 20 de abril. OpenID 2.0 y varios protocolos antiguos dejarían de funcionar. Una aplicación que no hubiera migrado podía sufrir una interrupción de su conexión con Google, incluso de la función de iniciar sesión, hasta adoptar un protocolo compatible. El anuncio describía una consecuencia posible, no un balance de incidentes. Dejaba claro quién podía apagar el punto de entrada antiguo.

La norma quedó lista con el reloj casi a cero

La OpenID Foundation votó la versión definitiva el 16 de abril de 2015: 28 votos favorables, ninguno en contra y cuatro abstenciones. Faltaban cuatro días para la fecha anunciada por Google. Eso no quiere decir que la industria tuviera cuatro días para empezar a programar. El proveedor había comunicado el fin en 2014 y la propia norma compara su texto con una guía de Google de junio de aquel año. Lo que llegó con cuatro días de margen fue el método común definitivo para unir de forma comprobable dos formas de identidad.

La especificación explica el choque de formatos. El viejo dato era el identificador reclamado y verificado de OpenID 2.0. El nuevo es una pareja de emisor y sujeto. El sitio añade el alcance openid2 a la petición de autenticación para solicitar ambos. Si el proveedor conoce el identificador anterior del usuario, lo incluye como openid2_id en el ID Token. El sitio valida ese token. Aún debe resolver una pregunta decisiva: ¿tiene el emisor nuevo autoridad para hablar en nombre del identificador antiguo?

Para responder, la norma permite un caso restringido de autoridad compartida entre los extremos antiguo y nuevo. En otros casos, el sitio consulta la URL del identificador antiguo con Accept: application/json y exige que el iss obtenido coincida exactamente con el emisor del token. Para los identificadores XRI define otra ruta. Si ninguna verificación de autoridad prospera, el sitio no debe aceptar la antigua identidad para el enlace. Solo después de comprobarla recomienda asociar la cuenta OpenID 2.0 existente con la identidad OpenID Connect. Ese acto ocurre en el registro de cuentas del sitio, donde están los derechos acumulados.

El apéndice B de la especificación compara sus reglas con la guía de migración de Google fechada en junio de 2014. Registra que la guía empleaba openid.realm donde la norma eligió openid2_realm, y openid_id donde eligió openid2_id. También afirma que aquella guía no incorporaba las comprobaciones del sitio solicitante y de la autoridad sobre el identificador antiguo descritas en el texto final. Es una comparación documentada por los autores de la norma con una guía de una fecha concreta; no es una auditoría de cada sistema que Google desplegó. Enseña por qué una migración de identidad no se agota en repetir instrucciones del proveedor que fijó la fecha.

Los registros citados no cuentan cuántos sitios terminaron la transición ni cuántas cuentas fueron vinculadas de forma incorrecta. Harían falta los ensayos y los registros de cada sitio. Sí muestran la división de poder: Google podía retirar un protocolo; el sitio que guardaba la cuenta debía decidir a quién se la entregaba.