Compreenda IAM, OAuth, OpenID Connect, SAML, SSO e JWT em um único artigo

O domínio de gerenciamento de identidade e acesso (IAM) tornou-se mais intricado nos últimos anos. Termos sofisticados como OAuth, OpenID Connect (OIDC), SAML, SSO e JWT são frequentemente usados, mas o que eles significam? Como eles funcionam juntos? Vamos explorar esses conceitos e frameworks para torná-los mais compreensíveis e práticos.

O que é IAM?#

Gerenciamento de identidade e acesso (IAM) é um conceito amplo que envolve o gerenciamento de identidades digitais e a implementação de controle de acesso. Os frameworks e protocolos mencionados anteriormente se enquadram no IAM, cada um abordando desafios específicos neste espaço.

Em essência, IAM trata de:

• Identidade: Uma representação digital de um usuário, serviço ou dispositivo. Uma identidade geralmente 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 usuário (identidade) quer realizar uma solicitação GET em uma API (recurso). Os atributos do usuário - nome, email e papel - descrevem a identidade.

Autenticação vs. autorização#

Autenticação e autorização muitas vezes aparecem juntas em discussões de IAM. Vamos esclarecer suas definições:

• Autenticação: O processo de verificar a posse de uma identidade. Responde à pergunta: "Qual identidade você possui?"
• Autorização: O processo de determinar quais ações uma identidade autenticada pode realizar em um recurso. Responde à pergunta: "O que você pode fazer?"

No exemplo anterior:

• Antes que o usuário (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 usuário pode realizar uma solicitação GET (ação) na API (recurso), ou seja, completar o processo de autorização.

---

Armado com esse conhecimento básico, vamos desmistificar os outros acrônimos e protocolos.

OAuth#

OAuth 2.0, comumente referido como OAuth, é um framework de autorização que permite que um aplicativo acesse recursos protegidos em outro aplicativo (normalmente em nome de um usuário).

Por exemplo, imagine que você tenha um aplicativo web chamado MyApp que deseja acessar o Google Drive de um usuário. Em vez de pedir ao usuário para compartilhar suas credenciais do Google Drive, MyApp pode usar OAuth 2.0 para solicitar permissão (autorização) do Google para acessar o Drive do usuário.

Aqui está um diagrama simplificado ilustrando o fluxo OAuth:

Neste fluxo:

• MyApp é o cliente (identidade) solicitando acesso ao Google Drive (recurso).
• O usuário (dono 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 usuário para acessar recursos. Para aprofundar-se, veja token de acesso.

OpenID Connect (OIDC)#

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

Se revisitarmos o fluxo OAuth, adicionando OIDC introduz um token de ID. Este token contém informações sobre o usuário autenticado e permite que o MyApp verifique a identidade do usuário.

Exemplo de cenário: "Entrar com Google"#

Vamos mudar de exemplo. Se o MyApp quiser permitir que os usuários façam login usando suas contas Google, o objetivo muda para autenticação, em vez de acesso a recursos. Neste caso, OIDC é mais adequado. Aqui está como o fluxo OIDC se parece:

Diferença chave: Além de um token de acesso, OIDC fornece um token de ID, que permite que o MyApp autentique o usuário sem exigir solicitações adicionais.

OIDC compartilha as definições de grant do OAuth 2.0, garantindo compatibilidade e consistência entre os dois frameworks.

SAML#

Security Assertion Markup Language (SAML) é um framework baseado em XML para trocar dados de autenticação e autorização entre partes. SAML, introduzido no início dos anos 2000, foi amplamente adotado em ambientes empresariais.

Como SAML se compara ao OIDC?#

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

• SAML: Usa assertivas baseadas em XML e é frequentemente considerado mais complexo.
• OIDC: Aproveita JSON e JWT, tornando-o mais leve e amigável para desenvolvedores.

Aplicações modernas muitas vezes preferem OIDC por sua simplicidade e flexibilidade, mas o SAML permanece prevalente em sistemas legados e em casos de uso empresariais.

Single sign-on (SSO)#

Single sign-on (SSO) é um esquema de autenticação que permite que os usuários acessem múltiplas aplicações e serviços com um único conjunto de credenciais. Em vez de entrar em cada aplicação individualmente, o usuário faz login uma vez e ganha acesso a todos os sistemas conectados.

Como o SSO funciona?#

SSO depende de um provedor de identidade (IdP) central para gerenciar identidades de usuários. O IdP autentica o usuário e fornece serviços como autenticação e autorização para aplicativos conectados.

O IdP pode usar protocolos como OIDC, OAuth 2.0, SAML ou outros para fornecer esses 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 usuário entra no IdP uma vez e é autenticado em várias aplicações (AppA e AppB).

SSO Empresarial#

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

Quando um cliente solicita o SSO para sua aplicação, é importante esclarecer suas necessidades e os protocolos que estão usando. Na maioria dos casos, isto significa que para domínios de e-mail específicos, eles querem que sua aplicação redirecione usuários para seu IdP (que implementa o SSO empresarial) para autenticação.

Exemplo: Adicionando um provedor de SSO empresarial#

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

JWT#

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

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

• Compacto: JWTs são objetos JSON codificados em um formato compacto, tornando-os fáceis de transmitir e armazenar.
• Autocontido: JWTs contêm todas as informações necessárias sobre o usuário e o próprio token.
• Verificável e criptografável: JWTs podem ser assinados e criptografados para garantir a integridade e confidencialidade dos dados.

Um JWT típico se parece com isto:

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

• Cabeçalho: Contém metadados sobre o token, como o tipo de token e o algoritmo de assinatura.
• Carga: 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 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 as informações do usuário sem fazer solicitações adicionais ao provedor de identidade. Para saber mais sobre JWT, visite JSON Web Token (JWT).

Recapitulação#

Cobrimos muitos tópicos neste artigo. Vamos resumir os pontos-chave com um exemplo:

Imagine que você tenha uma aplicação web, AppA, que requer uma solução de gerenciamento de identidade e acesso (IAM). Você escolhe Logto, um provedor de identidade que usa OpenID Connect (OIDC) para autenticação. Como OIDC é construído sobre o OAuth 2.0, o Logto também suporta autorização para sua aplicação.

Para reduzir o atrito para seus usuários, você habilita "Entrar com Google" no Logto. Isso usa OAuth 2.0 para trocar dados de autorização e informações do usuário entre o Logto e o Google.

Após o usuário fazer login no AppA via Logto, o AppA recebe um token de ID, que é um JSON Web Token (JWT) contendo as informações do usuário.

À medida que seu negócio cresce, você lança uma nova aplicação, AppB, que também precisa de autenticação de usuário. Como o Logto já está configurado, você pode reutilizar o mesmo fluxo de autenticação para o AppB. Seus usuários agora podem entrar tanto no AppA quanto no AppB com um único conjunto de credenciais, um recurso conhecido como single sign-on (SSO).

Mais tarde, um parceiro de negócios lhe pede para conectar seu sistema SSO empresarial, que usa Security Assertion Markup Language (SAML). Você descobre que o Logto suporta conexões SAML, então você configura uma conexão entre o Logto e o sistema SSO do parceiro. Agora, usuários da organização do parceiro também podem entrar no AppA e no AppB usando suas credenciais existentes.

---

Espero que este artigo tenha esclarecido esses conceitos para você. Para explicações mais detalhadas e exemplos, confira Auth Wiki. Se você está em busca de uma solução IAM para sua aplicação, considere usar um serviço gerenciado como Logto para economizar tempo e esforço.