Resumo

  • O OpenID Authentication 2.0 distinguia a URL reivindicada pela pessoa do identificador usado dentro do provedor. A pessoa podia conservar a URL ao mudar quem verificava suas credenciais.
  • Para preservar a conta, o site precisava descobrir o provedor indicado pela URL, conferir a afirmação recebida e usar a URL reivindicada como chave local. A especificação descreve essas obrigações; as fontes citadas não medem migrações realizadas.

O endereço era o ativo que deveria durar. Pela especificação final do OpenID Authentication 2.0, o usuário podia entregar a um site uma URL como sua identidade. O site consultava a informação publicada nesse endereço, encaminhava o navegador ao provedor de autenticação encontrado e conferia a resposta na volta. A senha ficava fora do site que aceitava o login. A OpenID Foundation anunciou a conclusão do texto em 5 de dezembro de 2007, junto de uma especificação distinta para troca de atributos. A disputa por controle estava na autenticação: quem tem o nome público precisa ser a mesma empresa que confere o segredo?

O protocolo deu nomes diferentes aos dois lados. O Claimed Identifier era o identificador que a pessoa afirmava controlar. O OP-Local Identifier era seu nome dentro do provedor, que talvez estivesse fora do seu controle. Se o site usasse o segundo nome para indexar a conta do usuário, uma troca de provedor poderia fazê-lo abrir um registro novo. O nome duradouro precisava ser o primeiro.

A descoberta por HTML mostrava como fazer a separação. A página da URL reivindicada podia conter um link rel="openid2.provider" apontando para o serviço de autenticação. Outro link, opcional, rel="openid2.local_id" indicava o nome da pessoa dentro desse serviço. O endereço da página podia estar num domínio diferente daquele do provedor. Quem controlasse a página podia mudar o destino do link do provedor sem trocar a URL apresentada aos sites onde possuía contas.

O site receptor tinha uma tarefa que o botão de login escondia. Ao receber uma afirmação positiva, precisava confirmar que havia descoberto o provedor para a URL reivindicada e que o endereço do provedor e o identificador local na resposta coincidiam com o que a descoberta mostrara. Se ainda não tivesse feito a consulta, deveria fazê-la naquele momento. Era a prova de que aquele provedor tinha autorização para falar pela URL. Aceitar qualquer afirmação sobre qualquer endereço destruiria a separação que o protocolo pretendia proteger.

Também era necessário escolher bem a coluna do cadastro. A especificação recomendava usar o identificador reivindicado como chave para guardar os dados locais da pessoa. Na compatibilidade com OpenID 1.1, a resposta antiga nem trazia openid.claimed_id. Quando o nome local do provedor diferia da URL reivindicada, o site precisava manter a URL usada na descoberta durante a sessão, para ligar a resposta à conta certa.

O OpenID afirmava dispensar uma autoridade central que aprovasse provedores e sites receptores. O usuário podia escolher o provedor e manter o identificador na mudança. Esse desenho exigia controle contínuo da URL, um ponteiro atualizado para o provedor e sites capazes de verificar a descoberta e manter as contas sob a chave certa. O texto não oferece uma contagem de implementações corretas ou de usuários que fizeram a troca com êxito.

A aposta histórica era permitir que a identidade pública saísse do domínio da empresa que verificava a senha. O provedor podia prestar o serviço hoje e perder o cliente amanhã sem levar o nome que ele usava em outros sites. Mas o site receptor mantinha a última palavra prática: se registrasse mal a conta, o usuário encontraria uma porta tecnicamente aberta e um cadastro que já não o reconhecia.

Registros originais