Gestão da Identidade: SAML vs. OAuth2 vs. OpenID Connect

Tudo começou com organizações que precisam de uma forma de centralizar os seus sistemas de autenticação para uma melhor gestão e segurança. Foi aí que o Single Sign On (SSO) entrou. Single Sign-on (SSO) é uma sessão centralizada e um serviço de autenticação de utilizadores em que um conjunto de credenciais de login pode ser utilizado para aceder a múltiplas aplicações. A sua beleza está na sua simplicidade; o serviço autentica-o numa única plataforma, permitindo-lhe entrar de forma transparente em vários serviços internos sem ter de entrar e sair de cada vez.

div>

P>Nextos vieram desenvolvedores de aplicações de terceiros que pretendiam utilizar APIs internas para as integrar com os seus produtos e soluções, isto foi claramente um desafio. Depois vieram as redes sociais e tornaram as coisas ainda mais complicadas, temos actualmente milhares de aplicações que apoiam a autenticação através de redes sociais como Facebook, Google, Twitter, LinkedIn, etc. O problema nestas arquitecturas é o desafio de manter as coisas tão simples quanto possível e, ao mesmo tempo, aumentar a segurança. A solução? Identidades Federadas.

Correntemente, os três principais protocolos para a identidade federada são: SAML, OAuth2 & OpenID Connect. Antes de mergulharmos fundo nestes três protocolos, vamos discutir alguns conceitos comuns que as pessoas tendem a confundir.

Quando se trata de segurança e acesso, autenticação & autorização são dois termos que as pessoas tendem a ignorar e que muitas vezes se enganam em significar a mesma coisa. Bem, autenticação é verificar a sua identidade enquanto autorização é verificar aquilo a que tem acesso.

Autenticação é validar as credenciais de login antes de dar ao utilizador acesso ao sistema. Quando se trata de segurança, recomenda-se a utilização de pelo menos dois factores de autenticação antes de conceder ao utilizador o acesso a qualquer coisa. (2FA, MFA, digital & fichas físicas, etc.).

div>

Autorização ocorre após o processo de autenticação, verificando os seus direitos antes de lhe conceder acesso aos recursos necessários, tais como bases de dados, ficheiros, repositórios, etc. Um exemplo prático seria, uma vez verificados os logins de um funcionário, ver a que andares tem acesso.

p>ambas as autorizações & autenticação são cruciais para a segurança e gestão do acesso e, embora ambos tenham conceitos diferentes por detrás, são críticos para a infra-estrutura de um sistema e a sua compreensão é fundamental para a gestão da identidade e do acesso.

SAML

Security Assertion Markup Language (SAML) é um padrão aberto baseado em XML utilizado para implementações de sinal único em (SSO). SAML 2.0 foi lançado em 2005 e é a versão actual do padrão.

SAML é usado para ambas as autenticações & autorização entre duas partes: um Provedor de Serviços (Office365, Salesforce, G Suite, etc.) & um Provedor de Identidade (Okta, OneLogin, Ping Identity, etc.). O Prestador de Serviços (SP) concorda em confiar no Provedor de Identidade (IdP) no processo de autenticação. Isto é feito através de um documento SAML XML enviado pelo IdP contendo a autorização do utilizador & autenticação e depois redireccionado para o prestador de serviços.

p>Vamos considerar este exemplo:

• Identity Provider (IdP): Okta
• Service Provider (SP): Aplicação Salesforce

1. O utilizador tenta entrar na aplicação Salesforce da sua empresa a partir de Chrome.
2. Aplicação Salesforce responde gerando um pedido SAML

li>Chrome redirecciona o utilizador para um URL SSO, Okta analisa o pedido SAML, autentica o utilizador (isto pode ser através de nome de utilizador e palavra-passe, autenticação de dois factores ou MFA é utilizador não está na rede interna da empresa; se o utilizador já estiver autenticado em Okta, esta etapa será ignorada) e gera uma resposta SAML.

3. Okta reenvia a resposta SAML codificada para Chrome
4. Chrome redirecciona a resposta SAML para a aplicação Salesforce
5. Se a verificação for bem sucedida, o utilizador será ligado à aplicação Salesforce e terá acesso a todos os vários recursos.

OAuth2

“Como posso permitir que uma aplicação aceda aos meus dados sem necessariamente lhe dar a minha palavra-chave?”

OAuth2 é um padrão aberto utilizado para autorização, permite que as aplicações forneçam a aplicação com “autorização delegada”. Ao contrário de outras estruturas que fornecem autenticação, OAuth apenas autoriza dispositivos, API, servidores com fichas de acesso em vez de credenciais e funciona sobre HTTPS.

Se alguma vez viu um dos diálogos abaixo, é disso que estamos a falar. Esta é uma aplicação que pergunta se pode aceder a dados em seu nome. Isto é OAuth.

p>Pode pensar nisto como cartões-chave de hotel, mas para aplicações. Se tiver um cartão-chave de hotel, pode ter acesso ao seu quarto. Como se obtém um cartão-chave de hotel? Tem de fazer um processo de autenticação na recepção para o obter. Depois de autenticar e obter o cartão chave, pode aceder a recursos em todo o hotel.

OAuth define quatro papéis:

li>Proprietário de recursos: Geralmente o próprio utilizador
• Cliente: Aplicação que solicita acesso a um servidor de recursos

li>Servidor de recursos: Servidor que hospeda dados protegidos (por exemplo, Facebook que hospeda o seu perfil e informações pessoais)Li>Servidor de autorização: Servidor que emite o token de acesso ao cliente. Este token será utilizado para o cliente solicitar o servidor de recursos.

Below é um diagrama do fluxo do OAuth2.

p>Vamos considerar este exemplo:

1. Spotify quer aceder à sua lista de amigos a partir da sua conta facebook.
2. É redireccionado por Spotify para o servidor de autorização (facebook neste caso)
3. Se autorizar o acesso, o servidor de autorização envia um código de autorização para o cliente (Spotify) na resposta de retorno da chamada.
4. Então, este código é trocado contra um código de acesso entre o Facebook e Spotify.
5. Agora Spotify é capaz de utilizar este código de acesso para consultar o servidor de recursos (Facebook) e recuperar a sua lista de amigos.

Uma coisa a notar é que o utilizador nunca chega a ver o código de acesso, ele será armazenado na sessão. O servidor de autorização também envia outras informações tais como a duração do token e um token de actualização.

OpenID Connect

OpenID Connect é uma camada de identidade simples no topo do protocolo OAuth 2.0 que prolonga o OAuth2 e permite a ‘Autenticação Federada’.

O fluxo do processo OpenID Connect é semelhante ao fluxo de autorização do OAuth2, sendo a principal diferença um ‘id-token’ que permite a autenticação do utilizador.

Nota que a Autenticação Federada é completamente diferente da Autorização Delegada. Tomemos novamente o exemplo do Facebook e Spotify

• Federated Authentication is logging to Spotify using your facebook credentials.
• Delegated Authorization is the ability of an external app to access resources. Neste caso, Spotify tenta aceder à sua lista de amigos do facebook para a importar para Spotify.

Para terminar, aqui está uma tabela que resume os três protocolos/frameworks.

/div>