Compreender IAM, OAuth, OpenID Connect, SAML, SSO e JWT num único artigo

O domínio da gestão de identidade e acesso (IAM) tornou-se mais intricado nos últimos anos. Os termos sofisticados como OAuth, OpenID Connect (OIDC), SAML, SSO e JWT são frequentemente usados, mas o que significam? Como funcionam em conjunto? Vamos explorar estes conceitos e frameworks para os tornar mais compreensíveis e práticos.

O que é IAM?#

Gestão de identidade e acesso (IAM) é um conceito abrangente que envolve gerir identidades digitais e implementar controle de acesso. As estruturas e protocolos mencionados anteriormente enquadram-se no IAM, cada um abordando desafios específicos neste espaço.

Essencialmente, IAM trata de:

• Identidade: Uma representação digital de um utilizador, serviço ou dispositivo. Uma identidade normalmente inclui atributos como nome, email, papéis, etc., para descrever a entidade.
• Acesso: A capacidade de interagir com recursos, realizar ações ou usar serviços. O acesso define quais ações podem ser realizadas em quais recursos.

No diagrama acima, um utilizador (identidade) quer realizar um pedido "GET" numa API (recurso). Os atributos do utilizador - nome, email e função - descrevem a identidade.

Autenticação vs. autorização#

Autenticação e autorização frequentemente aparecem juntas nas discussões sobre IAM. Vamos clarificar as suas definições:

• Autenticação: O processo de verificar a posse de uma identidade. Responde à questão, "Qual identidade tens?"
• Autorização: O processo de determinar quais ações uma identidade autenticada pode realizar num recurso. Responde à questão, "O que podes fazer?"

No exemplo anterior:

• Antes que o utilizador (identidade) possa realizar qualquer ação, ele deve completar o processo de autenticação.
• Após a autenticação, o sistema precisa determinar se o utilizador pode realizar um pedido "GET" (ação) na API (recurso), isto é, completar o processo de autorização.

---

Com este conhecimento fundamental, vamos desmistificar os outros acrónimos e protocolos.

OAuth#

OAuth 2.0, comumente referido como OAuth, é uma estrutura de autorização que permite a uma aplicação aceder a recursos protegidos noutra aplicação (tipicamente em nome de um utilizador).

Por exemplo, imagina que tens uma aplicação web chamada MyApp que quer aceder ao Google Drive de um utilizador. Em vez de pedir ao utilizador para partilhar as credenciais do Google Drive, o MyApp pode usar OAuth 2.0 para solicitar permissão (autorização) ao Google para aceder ao Drive do utilizador.

Aqui está um diagrama simplificado que ilustra o fluxo OAuth:

Neste fluxo:

• MyApp é o cliente (identidade) que está a solicitar acesso ao Google Drive (recurso).
• O utilizador (proprietário do recurso) concede permissão ao MyApp no passo 6, completando o processo de autorização.

Um elemento chave no OAuth 2.0 é o token de acesso, que o cliente usa para demonstrar a autorização do utilizador para aceder a recursos. Para uma exploração mais profunda, vê token de acesso.

OpenID Connect (OIDC)#

OpenID Connect (OIDC) é uma camada de autenticação construída sobre o OAuth 2.0. Adiciona funcionalidades especificamente para autenticação, como tokens de ID e um endpoint UserInfo, tornando-o adequado tanto para autenticação quanto para autorização.

Se revisitarmos o fluxo de OAuth, adicionar OIDC introduz um token de ID. Este token contém informação sobre o utilizador autenticado e permite ao MyApp verificar a identidade do utilizador.

Cenário de exemplo: "Iniciar sessão com Google"#

Vamos mudar de exemplo. Se o MyApp quiser permitir que os utilizadores iniciem sessão usando suas contas do Google, o objetivo muda para autenticação em vez de acesso a recursos. Neste caso, o OIDC é uma melhor escolha. Aqui está como o fluxo OIDC se parece:

Diferença Chave: Além de um token de acesso, o OIDC fornece um token de ID, que permite ao MyApp autenticar o utilizador sem necessitar de pedidos adicionais.

OIDC partilha definições de concessão do OAuth 2.0, garantindo compatibilidade e consistência entre os dois frameworks.

SAML#

Security Assertion Markup Language (SAML) é uma estrutura baseada em XML para a troca de dados de autenticação e autorização entre partes. Introduzido no início dos anos 2000, o SAML tem sido amplamente adotado em ambientes empresariais.

Como o SAML se compara ao OIDC?#

SAML e OIDC são funcionalmente semelhantes, mas diferem nos seus detalhes de implementação:

• SAML: Usa afirmações baseadas em XML e muitas vezes é considerado mais complexo.
• OIDC: Utiliza JSON e JWT, tornando-o mais leve e amigável para desenvolvedores.

Aplicações modernas preferem frequentemente o OIDC pela sua simplicidade e flexibilidade, mas o SAML continua prevalente em sistemas legados e em casos de uso empresarial.

Inicio único de sessão (SSO)#

Inicio único de sessão (SSO) é um esquema de autenticação que permite aos utilizadores aceder a várias aplicações e serviços com um único conjunto de credenciais. Em vez de fazer login em cada aplicação individualmente, o utilizador faz login uma vez e ganha acesso a todos os sistemas conectados.

Como funciona o SSO?#

O SSO depende de um fornecedor de identidade (IdP) central para gerir as identidades dos utilizadores. O IdP autentica o utilizador e fornece serviços como autenticação e autorização para as aplicações conectadas.

O IdP pode usar protocolos como OIDC, OAuth 2.0, SAML, ou outros para fornecer estes serviços. Um único IdP pode suportar múltiplos protocolos para atender às diversas necessidades de diferentes aplicações.

Exemplo de SSO baseado em OIDC#

Vamos explorar um exemplo de SSO baseado em OIDC:

Neste fluxo, o utilizador faz login no IdP uma vez e é autenticado através de várias aplicações (AppA e AppB).

SSO empresarial#

Enquanto o SSO é um conceito amplo, também poderás encontrar o termo SSO empresarial, que se refere a um tipo específico de SSO projetado para ambientes empresariais (tipicamente para funcionários e parceiros).

Quando um cliente solicita SSO para a tua aplicação, é importante esclarecer as suas necessidades e os protocolos que estão a usar. Na maioria dos casos, isso significa que para domínios de email específicos, eles querem que a tua aplicação redirecione os utilizadores para o seu IdP (que implementa SSO empresarial) para autenticação.

Exemplo: Adicionando um fornecedor de SSO empresarial#

Aqui está um exemplo simplificado de integração de um fornecedor de SSO empresarial (Banana) com a tua aplicação (MyApp):

JWT#

JSON Web Token (JWT) é um padrão aberto definido no RFC 7519 que permite a comunicação segura entre duas partes. É o formato padrão para tokens de ID em OIDC e é amplamente usado para tokens de acesso no OAuth 2.0.

Aqui estão as principais características do JWT:

• Compacto: Os JWTs são objetos JSON codificados num formato compacto, tornando-os fáceis de transmitir e armazenar.
• Autocontido: Os JWTs contêm toda a informação necessária sobre o utilizador e o próprio token.
• Verificável e encriptável: Os JWTs podem ser assinados e encriptados para garantir a integridade e confidencialidade dos dados.

Um JWT típico parece-se com isto:

Este JWT consiste em três partes separadas por pontos:

• Cabeçalho: Contém metadados sobre o token, como o tipo do token e o algoritmo de assinatura.
• Carga útil: Contém informações sobre a identidade e o próprio token.
• Assinatura: Verifica a integridade do token.

Tanto o cabeçalho quanto a carga útil são objetos JSON codificados em base64. O JWT acima pode ser decodificado da seguinte forma:

Usando JWT, o cliente pode decodificar o token e extrair a informação do utilizador sem fazer pedidos adicionais ao fornecedor de identidade. Para saber mais sobre JWT, visita JSON Web Token (JWT).

Recapitulação#

Cobrimos muitos pontos neste artigo. Vamos resumir os principais pontos com um exemplo:

Imagina que tens uma aplicação web, AppA, que necessita de uma solução de gestão de identidade e acesso (IAM). Escolhes Logto, um fornecedor de identidade que usa OpenID Connect (OIDC) para autenticação. Como o OIDC é construído sobre o OAuth 2.0, o Logto também suporta autorização para a tua aplicação.

Para reduzir a fricção para os teus utilizadores, ativa o "Iniciar sessão com Google" no Logto. Isto usa OAuth 2.0 para trocar dados de autorização e informações de utilizador entre o Logto e o Google.

Após o utilizador iniciar sessão na AppA via Logto, a AppA recebe um token de ID, que é um JSON Web Token (JWT) contendo a informação do utilizador.

À medida que o teu negócio cresce, lanças uma nova aplicação, AppB, que também necessita de autenticação de utilizadores. Uma vez que o Logto já está configurado, podes reutilizar o mesmo fluxo de autenticação para a AppB. Os teus utilizadores podem agora iniciar sessão tanto na AppA quanto na AppB com um único conjunto de credenciais, uma funcionalidade conhecida como inicio único de sessão (SSO).

Mais tarde, um parceiro de negócios pede para conectar o seu sistema de SSO empresarial, que usa Security Assertion Markup Language (SAML). Descobres que o Logto suporta conexões SAML, então configuras uma conexão entre o Logto e o sistema de SSO do parceiro. Agora, utilizadores da organização do parceiro também podem iniciar sessão na AppA e AppB usando as suas credenciais existentes.

---

Espero que este artigo tenha esclarecido estes conceitos para ti. Para explicações e exemplos mais detalhados, consulta a Auth Wiki. Se estás à procura de uma solução IAM para a tua aplicação, considera usar um serviço gerido como Logto para poupar tempo e esforço.