A senha, os cookies e o SAML

Até o final dos anos 90, o modelo de acesso baseado em login e senha parecia algo natural. Os dados de acesso eram gravados em um repositório, muitas vezes em formato de puro texto, sem sequer contar com alguma criptografia.

As primeiras iniciativas de evolução, para além do modelo Login e Senha, começaram a emergir por volta dos anos 2000, quando se passou a utilizar o controle de sessão, através de cookies introduzidos pelo browser, no computador do usuário.

Engenhosa para sua época, a autenticação por cookies de browser trazia um princípio interessante de agilização do acesso, dispensando o usuário de fazer novo login e digitar novamente a senha a cada site visitado. 

Mas a encriptação introduzida nesse processo, produzida pelo próprio navegador do usuário, ao longo das sucessivas sessões, tornou este modelo mais suscetível às violações por parte do mundo hacker. 

Somente cerca de cinco anos mais tarde, por volta de 2006, a comunidade de segurança e gerenciamento da identidade passa a experimentar o modelo de assinatura única, hoje considerado como “o mundo ideal”, que sobressai com o padrão OAuth. Atualmente, em fase de disseminação, o OAuth ganhou mais maturidade e facilidades de adoção, através da versão atual, OAuth 2.1. 

Antes dele, e surgido quase à mesma época, veio à tona, por iniciativa da OASIS (Organization for the Advancement of Structured Information Standards), o protocolo SAML (Security Assertion Markup Language).  Com o SAML, passa a ser possível trocar informações de autenticação entre diferentes sites e aplicações. 

SAML – Um novo cenário

Ele permite que um usuário, já logado em um domínio ou aplicação, obtenha autenticação certificada em outro domínio cooperado, valendo-se de um princípio de confiança recíproca entre estes domínios. 

Dessa forma, em vez de criar uma conta específica para cada serviço a ser acessado, o usuário assistido pelo SAML pode se beneficiar da autenticação já concedida em outro ponto formalmente reconhecido. Enquanto o OAuth endereça exclusivamente a questão da autorização, o SAML se apresenta como um protocolo de identidade, cobrindo tanto a autenticação quanto a autorização. 

Institui-se, dessa maneira, a categoria de domínios com o status de provedor de identidade confiável (IdP – Identity Provider), cujo endosso, em processos de autenticação, tem o poder de habilitar o usuário para o acesso ao ponto solicitado, sem exigir novas ações de identificação.  

Sem ter sido pensado, em termos estritos, como uma solução de assinatura única (Single Sign One), o SAML teve o mérito de introduzir o conceito de Autenticação Federada, a qual permite que diferentes domínios compartilhem credenciais de login e outras informações de identidade de forma segura. 

Apesar de suas virtudes e de sua resiliência, esse protocolo apresentou dificuldades praticamente insuperáveis de se consolidar para fora dos domínios internos da corporação. 

Sua arquitetura de transporte seguro de dados de identidade (PII- Personal Indetifiable Information) utiliza a transmissão de informações por código XML, com a aplicação de pilhas criptográficas. Isto  tornou-o excessivamente complexo, em termos de desenvolvimento e suporte, para efeito de federação entre diferentes domínios da Internet.

Entre as vantagens do SAML está a sua capacidade de gerar uma criptografia de fim a fim para os dados de identidade. Ou seja, é possível, através dele, gerar uma sessão de acesso controlado de ponta a ponta. Mas só um grupo restrito de empresas dispõe de capacitação técnica e recursos internos para projetar e gerenciar o transporte de criptografia sobre XML em nível cibernético.

Em face dessas limitações, o SAML não conquistou a disseminação massiva como padrão de autenticação federada para fora dos IdPs internos a um mesmo domínio. E sua aceitação no mercado só ganhou tração efetiva a partir do surgimento de aplicações de uso corporativo com suporte nativo ao protocolo, através de produtos de prateleira lançados por players líderes como Microsoft e Oracle. 

Afora  a aplicação de federação de identidade em nível de força de trabalho, alguns segmentos específicos implementaram o SAML em seu ecossistema setorial, devido à efetividade criptográfica de seu modelo de transporte PII, contornando portanto a complexidade inerente à sua arquitetura. 

No SAML existem basicamente três elementos centrais: o identity Provider (IdP), que comprova que “você” é realmente “você”, o Service Provider (que é a aplicação solicitada) e,  no meio do caminho “você mesmo” (o usuário), que comparece associado com o seu browser. 

Portanto, entre as características deste protocolo está o fato de que, nele, o Authorization Token é feito pelo browser do usuário, o que acrescenta um quê de vulnerabilidade àquele problema de complexidade para o tráfego de PII em XML.  

A vantagem de tal característica é a de que o Service Provider e o Identity Provider, no SAML, não necessitam de uma conexão direta entre si, com cada entidade realizando sua parte na autorização, de forma off-line, cada qual a seu lado. 

Sem esquecer a desvantagem já apontada mais acima:  a de que o browser não é, positivamente, um dos elementos mais seguros de uma estrutura de conexão. Então, reprisando, ele dispõe de um nível de confiança razoável no âmbito da rede corporativa, mas no mundo externo, na Internet, ele não está no controle dos participantes.

Mas é ilusório pensar que com a evolução dos protocolos abertos, a arquitetura de transporte em sistemas de identidade tenha se tornado algo simples.

Há mais de uma década atrás, a integração do OAuth com o Google exigia uma ação conjunta entre o interessado e o Google.  O mesmo valendo para a Microsoft ou o Facebook.

Se fosse necessário acrescentar um botão OAuth para se logar ao Instagram, seria necessário trabalhar com a equipe da própria  rede social. Mas o acúmulo de casos de uso e a aplicação estrita de protocolos permitiu uma descomplicação considerável.  

De tal forma que hoje a interoperabilidade de aplicações com OAuth OpenID já possibilita a integração de todo o sistema financeiro numa plataforma Open Finance segura e universal. 

Quer saber mais sobre autorização e autenticação?

E então, quer bater um papo e compartilhar nossos casos de uso?