Selecção de uma Estratégia SSO: SAML vs OAuth2

Chances are you’ve logged into an application (mobile app or web app) by click on a ‘Log in with Facebook’ button. Se usar Spotify, Rdio, ou Pinterest, então sabe do que estou a falar.

Como utilizador, provavelmente não se importa com o funcionamento de SSO. Apenas pretende utilizar uma aplicação e pode estar agradecido por uma experiência mais suave e por ter de se lembrar de menos logins e passwords.

Para fornecer a um utilizador um único sinal de experiência, um programador precisa de implementar uma solução SSO. Ao longo dos anos houve muitas tentativas de conseguir SSO, mas este artigo vai concentrar-se numa comparação entre SAML e OAuth2 – uma exploração recente que assumimos (felizmente saindo a outra ponta incólume, mas com muita informação).

A nossa necessidade de SSO

Estamos a trabalhar numa plataforma que terá várias aplicações clientes. Algumas destas aplicações serão baseadas na web, outras serão nativas, tais como aplicações móveis.

Esta plataforma será implementada sendo acessível a alguns clientes diferentes (pertencentes a diferentes organizações). Ao longo da estrada, pretende-se construir aplicações adicionais de terceiros em torno desta plataforma.

A plataforma é uma fachada para um sistema empresarial de grande dimensão que já tem informação de identidade sobre as pessoas que com ela interagiriam. Em vez de cada aplicação cliente manter a sua própria base de dados de utilizadores com nomes de utilizador e palavras-passe, parece mais apropriado utilizar SSO.

Sinal único ligado permitiria ao sistema empresarial armazenar com segurança e possuir todas as credenciais dos utilizadores. A plataforma pode estabelecer uma relação de confiança com o servidor de autenticação empresarial e as aplicações clientes podem ser construídas para utilizar o servidor de autenticação fiável para autenticar os utilizadores.

O nosso objectivo era identificar uma estratégia e implementação de SSO que pudesse apoiar estas necessidades.

Enter SAML 2.0

Inicialmente analisámos o SAML 2.0 que é um conjunto de padrões abertos, um dos quais foi especificamente concebido para SSO.

A especificação SAML 2.0 (doravante SAML) fornece um Perfil SSO de Navegador Web que descreve como se pode conseguir um único sinal ligado para aplicações Web. Existem três actores principais em SAML:

SAML e OAuth2 usam termos semelhantes para conceitos semelhantes. Para comparação, o termo formal SAML é listado com o equivalente a OAuth2 entre parênteses.

• Service Provider (Resource Server) – este é o servidor web em que está a tentar aceder à informação.

• p>Cliente – esta é a forma como o utilizador está a interagir com o Servidor de Recursos, como uma aplicação web a ser servida através de um navegador web.
• p>Fornecedor de Identidades (Servidor de Autorização) – este é o servidor que possui as identidades e credenciais do utilizador. É com ele que o utilizador realmente se autentica.

O fluxo SAML mais comum é mostrado abaixo:

SaML Web Browser SSO Profile flow

Aqui está um cenário fictício descrevendo o diagrama acima:

• A – um utilizador abre o seu web-browser e vai a MyPhotos.com que armazena todas as suas fotos. MyPhotos.com não trata da autenticação em si.

• B – para autenticar o utilizador MyPhotos.com constrói um SAML Authnrequest, assina-o, opcionalmente codifica-o, e codifica-o. Depois disso, redirecciona o navegador web do utilizador para o Provedor de Identidade (IdP), a fim de autenticar. O IdP recebe o pedido, descodifica-o, descodifica-o se necessário, e verifica a assinatura.

• p>C – Com um Authnrequest válido o IdP apresentará ao utilizador um formulário de login no qual pode introduzir o seu nome de utilizador e palavra-chave.

• D- Uma vez que o utilizador tenha feito login, o IdP gera um token SAML que inclui informação de identidade sobre o utilizador (como o seu nome de utilizador, e-mail, etc). O Id leva o token SAML e redirecciona o utilizador de volta ao Fornecedor de Serviços (MyPhotos.com).

• E – MyPhotos.com verifica o token SAML, descodifica-o se necessário, e extrai informações de identidade sobre o utilizador, tais como quem são e quais podem ser as suas permissões. MyPhotos.com regista agora o utilizador no seu sistema, presumivelmente com algum tipo de cookie e sessão.

No final do processo o utilizador pode interagir com MyPhotos.com como um utilizador registado. As credenciais do utilizador nunca passaram por MyPhotos.com, apenas através do Provedor de Identidade.

Existe mais detalhe no diagrama acima, mas este é de alto nível do que se passa.

Ao ser apresentado pela primeira vez ao SAML, o termo “ficha SAML” surgiu repetidamente. Não é na realidade um termo na especificação SAML, mas as pessoas continuaram a usá-lo, e o seu significado era elusivo.

Como se verifica, o termo “SAML token” parece ser uma forma coloquial de se referir à Assunção SAML, muitas vezes comprimida, codificada, possivelmente encriptada, e normalmente parece ser engolido. E uma Asserção SAML é apenas um nó XML com certos elementos.

SAML’s Native App Limitation

SAML suporta os conceitos de encadernação. Estes são essencialmente os meios pelos quais o Provedor de Identidade redirecciona o utilizador de volta para o Provedor de Serviços. Por exemplo, no passo D acima, o utilizador é redireccionado de volta para MyPhotos.com, mas como?

Os dois tipos relevantes de bindings são o HTTP Redirect e a ligação HTTP POST definida na especificação SAML 2.0. A encadernação HTTP Redirect utilizará um HTTP Redirect para enviar o utilizador de volta ao Fornecedor de Serviços, no caso do nosso exemplo: MyPhotos.com.

O encadernação HTTP Redirect é óptimo para mensagens curtas SAML, mas é desaconselhado o seu uso para mensagens mais longas, tais como afirmações SAML. Do wikipedia:

Mensagens mais longas (por exemplo, aquelas que contêm afirmações SAML assinadas) devem ser transmitidas através de outras encadernações, tais como a encadernação HTTP POST Binding.

A forma recomendada de utilização de um HTTP POST tem as suas próprias probabilidades. Por exemplo, a especificação SAML recomenda que o passo D acima apresente um formulário HTML onde a acção aponta de volta ao Fornecedor de Serviços.

P>Pode fazer o utilizador clicar noutro botão para submeter esse formulário ou pode utilizar o JavaScript para automatizar a submissão do formulário. Porque é que existe um formulário que precisa de ser submetido? Na minha opinião, SAML 2.0 está a mostrar a sua idade (cerca de 2005), uma vez que o formulário aqui só existe para que um HTTP POST possa ser utilizado para enviar a ficha SAML de volta ao Fornecedor de Serviços. O que, em defesa da SAML, em 2005, foi provavelmente uma decisão necessária na altura.

Este é um problema quando o cliente não é uma aplicação baseada na web, mas uma aplicação nativa, tal como uma aplicação móvel. Por exemplo, digamos que instalámos a aplicação MyPhotos iPhone. Abrimos a aplicação, e ela quer que nos autentiquemos contra o Provedor de Identidade. Uma vez autenticada, o Provedor de Identidade precisa de enviar o token SAML de volta à aplicação MyPhotos.

As aplicações móveis podem ser lançadas através de um URI personalizado, tal como, “my-photos://authenticate”, e presumivelmente, o Provedor de Identidade submete o formulário que inclui o token SAML a esse URL. O nosso aplicativo MyPhotos é lançado, mas não estamos conectados. O que dá?

Aplicações móveis não têm acesso ao corpo do HTTP POST. Só têm acesso ao uso do URL para lançar a aplicação. Isto significa que não podemos ler a ficha SAML.

No Android: lançando uma aplicação a partir de uma url usando Intents.

No iOS: lançando uma aplicação registando um esquema URI personalizado.

Sem ficha SAML, sem utilizador autenticado.

Trabalhar em torno da ligação POST HTTP do SAML

A limitação da ligação POST HTTP para aplicações móveis nativas pode ser trabalhada em torno. Por exemplo, é possível utilizar vistas Web incorporadas, nas quais se escreve código personalizado para assistir a todo o processo de autenticação. No final do processo, raspa-se o HTML da página e extrai-se o token SAML.

Uma segunda alternativa é implementar um servidor proxy que possa receber o HTTP POST, extrair o token SAML, e depois fazer um URL que inclua o token SAML (por exemplo: “myphotos://authenticate/?SAMLRequest=asdfsdfsdf”) O servidor proxy poderia então usar um HTTP Redirect para fazer com que o dispositivo abrisse a aplicação MyPhotos. E como a ficha SAML faz parte da URL, a aplicação MyPhotos pode extraí-la, e utilizá-la para iniciar sessão.

Uma terceira alternativa seria ignorar a recomendação da especificação contra a utilização da ligação HTTP Redirect. Isto é muito tentador, mas é difícil livrar-se da sensação de que se está a entrar num campo minado, esperando apenas que não se dê um passo em falso.

Outra abordagem que evitou completamente as soluções é não confiar no SAML, mas olhar para outra abordagem, como OAuth 2.0.

Enter OAuth 2.0

Unlike SAML, OAuth 2.0 (doravante OAuth2), é uma especificação cuja tinta mal secou (cerca do final de 2012). Tem a vantagem de ser recente e tem em consideração como o mundo mudou nos últimos oito anos.

Dispositivos móveis e aplicações nativas são hoje prevalecentes de formas que o SAML não poderia antecipar em 2005.

Os intervenientes básicos com OAuth2 são:

SAML e OAuth2 utilizam termos semelhantes para conceitos semelhantes. Para comparação o termo formal OAuth2 é listado com o equivalente SAML entre parênteses.

• p>p>Servidor de Recursos (Fornecedor de Serviços) – este é o servidor web em que está a tentar aceder à informação.

• Cliente – é assim que o utilizador está a interagir com o Servidor de Recursos. Pode ser uma aplicação web baseada num browser, uma aplicação móvel nativa, uma aplicação desktop, uma aplicação do lado do servidor.

• Servidor de autorização (Provedor de Identidade) – este é o servidor que possui as identidades e credenciais do utilizador. É com quem o utilizador realmente se autentica e autoriza.

A um nível elevado, o fluxo OAuth2 não é muito diferente do fluxo SAML anterior:

P>P>Vamo-nos embora no mesmo cenário por onde andámos anteriormente com o SAML:

• p>A – um utilizador abre o seu navegador web e vai a MyPhotos.com que armazena todas as suas fotografias. MyPhotos.com não trata da autenticação em si, pelo que o utilizador é redireccionado para o Servidor de Autorização com um pedido de autorização. O utilizador é apresentado com um formulário de login e é-lhe perguntado se deseja aprovar o Servidor de Recursos (MyPhotos.com) para agir em seu nome. O utilizador inicia sessão e é redireccionado de volta para MyPhotos.com.
• p>B – o cliente recebe um código de concessão de autorização como parte do redireccionamento e depois passa-o para o cliente.
• p>C – o Cliente utiliza então esse código de concessão de autorização para solicitar um código de acesso ao Servidor de Autorização.
• p>D – se o código de concessão de autorização for válido, então o Servidor de Autorização concede um código de acesso. O código de acesso é então utilizado pelo cliente para solicitar recursos do Servidor de Recursos (MyPhotos.com).

• E – MyPhotos.com recebe o pedido de um recurso e recebe o código de acesso. A fim de garantir que é um token de acesso válido, envia o token directamente para o Servidor de Autorização para validar. Se for válido, o Servidor de Autorização envia de volta informações sobre o utilizador.

• p>F – tendo validado o pedido do utilizador MyPhotos.com envia o recurso solicitado de volta ao utilizador.

Este é o fluxo OAuth2 mais comum: o fluxo do código de autorização. OAuth2 fornece três outros fluxos (ou o que eles chamam autorizações concedidas) que funcionam para cenários ligeiramente diferentes, tais como aplicações javascript de página única, aplicações móveis nativas, aplicações desktop nativas, aplicações web tradicionais, e aplicações do lado do servidor onde um utilizador não está directamente envolvido, mas que lhe concederam permissão para fazer algo em seu nome.

A grande vantagem com os fluxos OAuth2 é que a comunicação do Servidor de Autorização de volta para o Cliente e o Servidor de Recursos é feita através de HTTP Redirecciona com as informações token fornecidas como parâmetros de consulta. OAuth2 também não assume que o Cliente é um navegador web, enquanto que o SAML Web Browser SSO Profile por defeito faz.

Aplicações móveis nativas funcionarão apenas fora da caixa. Não são necessárias soluções de trabalho.

Frases Favoritas de OAuth2: Out of Scope

A especificação OAuth2 não prescreve como a comunicação entre o Servidor de Recursos e o Servidor de Autorização funciona em muitas situações, tais como a validação de um token. Também não diz nada sobre que informação deve ser devolvida sobre o utilizador ou em que formato.

Há bastantes pontos em que a especificação OAuth2 afirma que as coisas estão “fora do âmbito desta especificação”. Isto trouxe críticas à especificação OAuth2 porque deixa muitas coisas para implementação que poderiam levar a implementações incompatíveis em algum ponto.

OAuth2, é ainda muito jovem, e já tem uma adopção generalizada com o Google, Facebook, Salesforce, e Twitter para citar alguns. A verdadeira beleza de OAuth2, no entanto, é a sua simplicidade. Na verdade, o OpenID Connect Basic Profile, que se baseia em OAuth2 preenche algumas das áreas que a própria especificação OAuth2 não define.

OAuth2: Não requer assinaturas digitais por defeito

OAuth2 não requer mensagens de assinatura por defeito. Se quiser acrescentar isso, sinta-se à vontade, mas fora da caixa, a especificação funciona sem ela. Prescreve que todos os pedidos devem ser feitos sobre SSL/TLS.

Isto causou comoção no passado:

• OAuth 2.0 (sem Assinaturas) é Mau para a Web
• OAuth 2.0 e o Road to Hell

Having trabalhou com OAuth2 e OAuth1 no passado, posso dizer que OAuth2 é muito mais simples do que OAuth1 (e mais agradável de trabalhar com). Interoperabilidade e descoberta automática de serviços pode ser algo útil no futuro, mas neste momento, não é nada que estejamos à procura.

Pode-nos ser pedido que assinemos mensagens assim que a equipa de segurança da empresa faça a auditoria final da implementação do OAuth2, mas por agora, o OAuth2 enquadra-se nos nossos objectivos actuais de uma forma mais padronizada do que o SAML. É também muito mais simples.

Se cada aplicação tiver um servidor web seguro de apoio, então a assinatura funciona bem, mas quando não é esse o caso, o problema torna-se mais matizado. Como é que se guarda em segurança as chaves no navegador para aplicações JS baseadas no navegador ou em aplicações móveis nativas?

Se utilizar o Google para descompilar aplicações iOS e Android, o seu coração afundar-se-á. As suas chaves não são realmente tão seguras se não puder possuir e proteger o dispositivo.

OAuth2 é para Autorização, não para Autenticação

O “auth” no OAuth significa “Autorização” e não “Autenticação”. O pedante em si pode estar a sorrir. Apanhou-me!

Mas – sim, há sempre um mas! Embora o termo OAuth seja bastante recente, o facto de “auth” significar autorização parece um pouco anacrónico. Já está a ser usado para conseguir SSO na selva (graças a sites como o Facebook, Twitter, Salesforce, e Google e milhares de sites que os utilizam para autenticar e autorizar utilizadores).

A maior queixa que já vi é a falta de prescrição e a utilização abundante “fora de alcance” nas especificações do OAuth2. O facto de o OpenID Connect Basic Profile ser construído directamente sobre o OAuth2 deveria ser suficiente para dissipar o mito de que OAuth2 não pode ser usado para autenticação.

O que uma palavra há seis anos atrás significava é muito menos importante do que aquilo que pode abranger hoje.

Sumário

SAML tem uma característica que falta ao OAuth2: o símbolo SAML contém a informação de identidade do utilizador (por causa da assinatura). Com OAuth2, não se obtém isso da caixa, e em vez disso, o Servidor de Recursos precisa de fazer uma viagem adicional de ida e volta para validar o token com o Servidor de Autorização.

Por outro lado, com OAuth2 pode invalidar um token de acesso no Servidor de Autorização, e desabilitá-lo de um acesso adicional ao Servidor de Recursos.

As duas abordagens têm características agradáveis e ambas funcionarão para SSO. Temos provado ambos os conceitos em várias línguas e vários tipos de aplicações. No final do dia, o OAuth2 parece ser mais adequado às nossas necessidades (uma vez que não existe uma infra-estrutura SAML existente para utilizar).

OAuth2 fornece uma solução mais simples e padronizada que cobre todas as nossas necessidades actuais e evita a utilização de soluções de trabalho para a interoperabilidade com aplicações nativas.

Quando isto começar a desdobrar-se e trabalharmos com várias equipas de segurança, veremos até onde isto vai.

Tão longe, tão bom.