OpenID Connect para Curiosos
Este artigo tem a finalidade de explicar o conceito do OpenID Connect não se aprofundando na parte técnica.
História do OpenID
O OpenID Connect é a terceira geração do protocolo de autenticação OpenID criado pela Fundação OpenID (também conhecida como OIDF), uma organização internacional de padronização sem fins lucrativos que foi formada em junho de 2007 e que tem como objetivo servir como uma organização de confiança pública, representar a comunidade aberta de desenvolvedores e também gerenciar a propriedade intelectual e as marcas, promovendo globalmente a utilização do OpenID.
O protocolo de autenticação OpenID tem como finalidade permitir que os usuários sejam autenticados por sites cooperantes (conhecidos como partes confiáveis ou RP) usando um serviço de autorização de terceiros. Isso elimina a necessidade de aplicativos web e aplicativos nativos ter que fornecer as suas próprias soluções de autenticação e também permite que os usuários consigam acessá-los utilizando o mesmo usuário e senha.
A primeira geração conhecida apenas como OpenID foi publicada em maio de 2005 (antes da criação da Fundação OpenID) por Brad Fitzpatrick, criador do popular site comunitário LiveJournal e não foi adotada amplamente. A segunda geração, conhecida como OpenID v2.0, foi publicada em dezembro de 2007 e teve muito mais adoção e maturidade, porém ainda havia limitações de design, as partes confiáveis podiam ser apenas aplicativos web (não aceitava aplicativos nativos) e utilizava XML. Já a terceira geração, conhecida como OpenID Connect 1.0 ou OIDC, foi publicada em novembro de 2014 e funciona como uma camada simples de identidade sobre o protocolo OAuth 2.0 e tem como base as lições aprendidas com os primeiros protocolos OpenID e SAML2 tendo como princípio:
- Manter as coisas simples
- Construir sobre o OAuth 2.0
- Usar tokens fáceis de consumir (JWT)
OAuth 2.0
O OAuth 2.0 é um protocolo de autorização e define fluxos seguros para proceder à autenticação e à autorização de usuários no acesso a sistemas de informação. De fato, o OAuth 2.0, ao definir uma entidade conhecida por servidor de autorização (um serviço que cuida da autenticação e autorização de usuários) deu origem a um vasto mercado para empresas que gerenciam credenciais de usuários (esse mercado é hoje dominado por empresas como Google, Facebook e Okta — lembra do botão “login com Google”, ou “Entrar com o Facebook” que aparece em grande parte das telas de autenticação ?— eles são possíveis graças à aderência de sistemas ao protocolo OAuth 2.0).
Porém, o OAuth 2.0 pouco diz a respeito das informações que devem ser trocadas entre as partes do processo de autenticação. Ele fala de serviços especializados em autenticação, de tokens de acesso e tokens de refresh e define vários fluxos seguros para autenticação e autorização de usuários. Mas ele nunca detalha o modo como a autenticação deve ser realizada (isto é, usuário e senha, segundo fator, biometria). O OpenID Connect vem justamente tornar um pouco mais concretas as definições abstratas do OAuth 2.0.
Clique aqui para saber mais sobre o OAuth 2.0
OpenID Connect
A especificação do OpenID Connect representa o consenso de especialistas sobre a melhor forma para a troca segura de informações de autenticação e dados pessoais de usuários entre os aplicativos clientes e o servidor de autorização. Resumidamente, o OpenID Connect traz três definições principais.
Em primeiro lugar, ele especifica como os aplicativos clientes podem pedir que o servidor de autorização utilize métodos específicos para autenticação de usuários. Aqui cabe notar que o OpenID Connect não define métodos de autenticação, mas pede que seja aplicado um método específico entre aqueles oferecidos pelo servidor de autorização.
Em segundo lugar, caso o aplicativo cliente não deseje especificar o método de autenticação, o OpenID Connect oferece meios para que, pelo menos, o aplicativo cliente seja cientificado pelo servidor de autorização sobre o método que foi utilizado. Dessa forma, dependendo da força do método de autenticação, o aplicativo cliente pode decidir sobre oferecer ou não serviços mais sensíveis ao usuário, como, por exemplo, que envolvam valores financeiros. Em terceiro lugar, o OpenID Connect define um método para fazer a transferência segura de dados pessoais do usuário entre o servidor de autorização e o aplicativo cliente.
Quando um aplicativo cliente realiza a autenticação de um usuário utilizando um Servidor de Autorização que não usa o OpenID Connect, o aplicativo cliente recebe de volta apenas um Token de Acesso contendo as permissões que o usuário possui e que é utilizada pelo aplicativo cliente para saber se ele tem permissão ou não a determinadas funcionalidades da aplicação. Quando um aplicativo cliente realiza a autenticação de um usuário utilizando um Servidor de Autorização que adota o OpenID Connect, o aplicativo cliente recebe de volta um Token de Acesso e também um Token de Identidade contendo algumas informações adicionais do usuário.
Fluxo de Autenticação utilizando Servidor OpenID
- O aplicativo cliente envia uma solicitação de autenticação para o Servidor OpenID (nome dado ao Servidor de Autorização que utiliza o protocolo OpenID Connect) informando quais são as permissões e quais as informações pessoais do usuário o aplicativo cliente deseja.
- O Servidor OpenID autentica o usuário a partir das suas credenciais. Isso pode ocorrer de forma automática se o usuário já estiver autenticado ou através da solicitação das credenciais ao usuário.
- Depois, o Servidor OpenID solicita o consentimento do usuário para devolver todas as informações solicitadas pelo aplicativo cliente. Isso acontece caso o usuário ainda não tenha feito o consentimento ou caso o aplicativo cliente solicite alguma informação nova.
- Por fim o Servidor OpenID devolve para o aplicativo cliente um Token de Acesso e pode devolver também um Token de Identificação caso solicitado pelo aplicativo cliente.
- O aplicativo cliente pode obter informações pessoais do usuário diretamente do Token de Identidade recebido ou solicitar para o Servidor OpenID usando o Token de Acesso.
- O Servidor OpenID devolve as informações pessoais do usuário. Sempre que o aplicativo cliente solicitar alguma informação nova, o Servidor OpenID deverá pedir o consentimento do usuário para poder devolver a informação para o aplicativo cliente.
Falando um pouco mais sobre os Tokens
Token de Identidade: é um token de segurança gerado normalmente no formato JWT e funciona como um cartão de identidade que permite ao aplicativo cliente verificar a autenticidade do usuário e obter informações adicionais, como e-mail, celular, nome completo, foto e etc. Para receber essas informações, o aplicativo cliente deverá informar ao Servidor OpenID no momento de autenticação a necessidade da geração do Token de Identidade, que por sua vez deverá solicitar o consentimento do usuário para o envio das informações. Essas informações geralmente são utilizadas para exibir interfaces personalizadas e mais agradáveis para o usuário final.
Token de Acesso: é uma credencial gerada normalmente no formato JWT e que pode ser utilizada pelo aplicativo cliente para conceder acesso a funcionalidades específicas do próprio aplicativo cliente que solicitou o Token de Acesso ou para funcionalidades específicas de um aplicativo de terceiro. Esse tipo de Token tem a função de informar à API que o seu portador possui acesso a funções específicas, de acordo com os escopos solicitados e, quando necessário, com o consentimento do usuário.
Charles Schiavinato é Desenvolvedor na Acesso Digital.
