Brad Fitzpatric tomou a iniciativa de desenvolver o protocolo OpenID, e em 2005 sua primeira versão estava pronta. O protocolo OpenID é uma solução Single Sign-On para a internet. A primeira implementação do protocolo foi utilizada no site Livejournal.com.
Primeiramente, antes de entrarmos no funcionamento do OpenID de fato, é necessário apresentarmos a terminologia adotada para a representação deste protocolo.
A arquitetura OpenID é composta por três tipos de agentes:
Usuário: Um programa, como um browser, utilizado pelo usuário final para acessar um website (relying party) e autenticar-se utilizando uma identidade OpenID obtida de um provedor OpenID de sua escolha;
Provedor OpenID (OP): Um servidor de autenticação que fornece uma ou mais identidades para o usuário final, e valida as credenciais do usuário em nome do website onde deseja-se conecta.O usuário tem a liberdade para escolher um provedor OpenID no qual confie;
Relying Party (RP): O website onde o usuário deseja conectar-se, utilizando um identificador OpenID. Esse identificador será validado pelo provedor OpenID do usuário.
O processo de autenticação utilizando o protocolo OpenID é representado pelos passos a seguir:
Figura 2: Representação do processo de autenticação
Quando um usuário conecta-se a um website (RP), o RP pede ao usuário seu login e senha e o usuário entra então com seu identificador único OpenID, que pode ser uma URL, como http://exemplo.com/usuario, ou um XRI (extensive resource identifier), como xri://=exemplo.usuario.
Em seguida, o RP utiliza o identificador enviado pelo usuário para descobrir qual o provedor OpenID (OP) utilizado para autenticação do usuário. Essa descoberta pode ser realizada utilizando o documento HTML da URL inserida pelo usuário ou utilizando o protocolo Yadis. Os processos de descoberta serão melhor abordados adiante. Quando o RP descobre o provedor utilizado, redireciona o usuário para ele e enviando um pedido de autenticação OpenID.
Quando o usuário é redirecionado, uma nova conexão é estabelecida, agora entre usuário e provedor, para realizar a autenticação. O método de autenticação realizado pelo provedor não é especificado pelo protocolo OpenID. Sendo assim, o provedor pode escolher que método de autenticação utilizar. Em geral, o usuário precisa fornecer um username e senha cadastrados em seu provedor OpenID, e em seguida deve confirmar o pedido de autenticação do RP, que inclui quais das suas informações pessoais poderão ser fornecidas.
Caso as informações inseridas pelo usuário estejam de acordo com sua autenticação, o provedor então informa ao RP que o usuário foi autenticado com sucesso e o redireciona para o RP. Após a validação da confirmação do provedor pelo RP, o usuário terá sua sessão iniciada e poderá navegar normalmente.
Depois do processo de autenticação OpenID, o usuário pode tentar utilizar um outro serviço ou um novo RP, representado na figura abaixo como RP 2, que suporta o protocolo OpenID. Nesse caso a autenticação pode ser caracterizada pelo método Single Sign-On, pois para autenticar-se no novo RP o usuário não precisa entrar com seus dados de autenticação novamente na página de seu OP, bastando fornecer seu identificador OpenID no RP. O processo, que é baseado no sistema de cookies, pode ser representado da seguinte forma:
Figura 3: Representação da autenticação única
Quando o usuário conecta-se ao RP 2, o RP pede as informação de autenticação do usuário que então entra com seu identificador OpenID.
O RP envia ao OP o pedido de autenticação do usuário. Em seguida, o browser do usuário fornece ao OP o id da sessão enviada pelo OP anteriormente, quando o usuário fez sua primeira autenticação. O id é então verificado.
O OP então pergunta ao usuário se ele permite a autenticação no RP 2 somente dessa vez, sempre ou se não permite.
Se o usuário permitir a autenticação no RP 2, o OP envia a permissão para o RP e redireciona o usuário para ele. O usuário pode então navegar normalmente, sem ter precisado entrar novamente com seus dados de autenticação no OP.
Como foi mencionado no processo de autenticação anteriormente, o RP realiza um processo de descoberta para identificar qual o provedor utilizado pelo usuário. Essa descoberta pode ser realizada através de três métodos:
Se o usuário inseriu um XRI (extensive resource identifier), então um protocolo XRI será utilizado para obter um documento XRDS (extensible resource desciptor sequence).
Se o usuário inseriu uma URL, então o protocolo Yadis deve ser usado para obter um documento XRDS.
Se o usuário inseriu uma URL mas o protocolo Yadis não pode ser utilizado, então o RP deve utilizar o documento HTML localizado na URL fornecida.
Se nenhum desses métodos estiver disponível, então o RP não pode encontrar o provedor OpenID e o processo de autenticação não pode ser realizado.
O documento XRDS é um documento no formato XML que armazena as informações do provedor OpenID.
Se a descoberta for feita através do documento HTML apontado por uma URL inserida pelo usuário, em geral procura-se por um uma tag <link> na parte <head> do HTML da página. Essa tag <link> deve incluir o valor rel="openid.provider" ou rel="openid2.provider", dependendo da versão do protocolo. Nesta tag também será encontrada um href que define o endereço do provedor OpenID onde a autenticação do usuário se encontra, como por exemplo http://exemplo.org/openid-auth/.
Figura 4: Logo do Protocolo Yadis
O RP pode utilizar o protocolo Yadis para encontrar o provedor OpenID, através de um identificador. O protocolo Yadis utiliza HTTP como protocolo de transferência. Um ID Yadis é um identificador que pode ser traduzido em uma URL e que é necessário para iniciar o protocolo Yadis.
Quando um serviço, como um RP, deseja utilizar o protocolo Yadis para obter um documento XRDS, o serviço deve enviar um pedido HTTP para um ID Yadis. Podem haver três respostas ao pedido:
A resposta contém um arquivo XRDS.
A resposta contém um documento HTML com um link para o documento XRDS.
Ou a resposta pode conter um campo de cabeçalho que contém um link para um documento XRDS.
Se a resposta contém um documento HTML com a referência para o documento XRDS, então o serviço precisa fazer um novo pedido HTTP endereçado para a localização do documento. Quando o documento XRDS é recebido o protocolo é finalizado.