O OAuth surgiu há cerca de 10 anos, portanto, em paralelo à evolução do SAML, com a missão de ser um protocolo mais aderente à Internet e com menor exigência de esforço técnico na sua implementação. Isso se deve ao fato de não envolver o transporte de PII, em virtude de funcionar exclusivamente como solução de autorização, e não como certificador.
Especificado pela comunidade internacional aberta IETF (Internet Engineering Task Force), o OAuth foi projetado para permitir que usuários possam logar em sites de terceiros simplesmente autorizando estes sites a requisitarem credencias, já registradas em IdPs de reputação reconhecida.
IdPs esses que podem ser tanto aplicações internas ou sites de parceiros com acreditação recíproca, quanto grandes players coletores de identidade, como o Google, Amazon ou Twitter.
Se, de um lado, o OAuth, em sua arquitetura original, conta com a facilidade de não precisar transportar PII e, portanto, não expor a credencial do usuário, como já foi enfatizado, este protocolo tampouco endereça o problema da autenticação, ficando, com esta defasagem, a exigir a combinação com autenticadores com requisitos de segurança e interoperabilidade.
Assim, enquanto o padrão SAML, bem ou mal, dispõe de maquinaria completa para transportar dados de identidade e, portanto, para prover autenticação de ponta a ponta, o OAuth opera apenas solicitações e processamento de autorização cooperada para o servidor de acesso, de modo a agilizar o provimento do serviço, mas sem informar à aplicação os dados de credencial de usuário.
A notória complexidade do SAML para responder a uma parte essencial de sua missão, que é o transporte seguro de PII (e, portanto, de se espraiar para o universo extra domínio interno) não representou a condenação cabal de sua bem sucedida abordagem de autenticação federada.
Por seu funcionamento satisfatório e mais fácil de implementar no nível intra-domínio, especialmente no gerenciamento de IdPs voltados para o workforce, o SAML continuou sua trajetória. Tanto assim que atraiu a atenção da comunidade aberta global OpenID Foundation como possível base para um protocolo tão flexível quanto o OAuth, mas dotado dos requisitos necessários para abordar também a identidade e sua autenticação.
Partindo a essa procura, entre 2005 e 2007, a OpenID Foundation sobrepôs as pilhas de autorização do OAuth ao alicerce de serviços de autenticação federada do SAML e criou novos requisitos de interoperabilidade entre esses dois protocolos, uma tarefa ainda em andamento.
Dessa forma, foi possível apresentar ao mercado um novo protocolo aberto que foi batizado como OpenID Connect, e que viria rapidamente a liderar os processos de resolução de serviços de identidade.
Logo a OpenID Foundation se deu conta, porém, de que a nova proposição, na primeira versão do OAuth, repetia o erro que encavalar complicados códigos de encriptação sobre codificação XML, resultando num tipo de algoritmo praticamente inviável de ser gerenciado por uma empresa comum, com sua capacidade interna de TI e Segurança.
Esta primeira iniciativa precisou, por isso, passar por uma ‘retrovisão’, retornando-se a arquitetura de federação para um ponto mais próximo do SAML, porém com uma linguagem de transporte de dados de identidade mais simples e flexível (formato Json) e tornando mais segura e menos complexa a troca de autenticação entre as partes confiáveis.
Com esta camada de identidade construída a partir do SAML, em combinação com o autorizador do OAuth, o OpenID Connect consegue minimizar as antigas dificuldades inerentes ao transporte de PII, instituindo um ID Token mais compatível com a capacidade de engenharia e suporte das empresas.
Ao mesmo tempo, o OpenID oferece maior tranquilidade quanto ao transporte de dados de identidade e HTTP. Isto porque, embora ele também realize este transporte pelo browser, e embora use “Authorization Flow Code” na chamada de call-back do navegador, a troca do token real (Token ID), que é o que interessa, acontece em backchannel.
De tal forma que hoje a interoperabilidade de aplicações com estes protocolos já possibilita a integração de todo o sistema financeiro global numa plataforma Open Finance segura e com nível notável de maturidade.
Portanto, OAuth e OpenID representam hoje o estado da arte em termos de protocolos de autenticação e autorização. Mas ambos estão ainda em fase inicial, do ponto de vista da escala, principalmente quando se pensa na complexa economia em rede e se observa a tendência de convergência de negócios, na qual os bancos tendem a se tornar varejo e o varejo tende a se tornar bancos, da mesma forma que as empresas de comunicação caminham para explorar esses nichos.
Seja com o for, é razoável pressupor que a força de tração da indústria financeira repercuta numa adesão – horizontal e em profundidade – do OAuth 2.1 e do OpenID Connect no futuro próximo.
