top of page
Buscar

OAuth, OIDC, SAML e SCIM: qual protocolo usar e quando

Foto do escritor: Wanderson Marchi
Wanderson Marchi
há 20 horas
6 min de leitura

Toda semana alguém escreve "vamos usar OAuth para o login". Quase sempre a frase está errada, e o erro não é só de vocabulário: ele costuma virar uma falha de segurança. Quatro siglas, OAuth, OIDC, SAML e SCIM, aparecem juntas em qualquer projeto de identidade e quase sempre são confundidas entre si.

A saída é parar de decorar siglas e começar pelo problema. Cada protocolo existe para resolver uma pergunta diferente. Quando a pergunta está clara, a escolha fica quase automática.


Quatro problemas, quatro protocolos

Pergunta

Problema

Protocolo

"Esta aplicação pode acessar esses dados em meu nome?"

Autorizar (delegar acesso)

OAuth 2.0

"Como meu aplicativo descobre quem é o usuário que acabou de fazer login, sem eu guardar senha?"

Autenticar em aplicações modernas

OpenID Connect (OIDC)

"Como o funcionário usa o login da empresa para acessar o sistema de um fornecedor, sem criar outra conta?"

Federar identidade corporativa

SAML 2.0

"Quando alguém é contratado ou desligado, quem cria e remove a conta em cada sistema?"

Provisionar e desprovisionar

SCIM 2.0

Os três primeiros tratam do momento do acesso. O quarto trata do que acontece antes e depois dele, e é o que costuma ser esquecido.


OAuth 2.0: delegação de acesso, não login

O OAuth 2.0 (RFC 6749) nasceu para resolver um problema simples: como permitir que uma aplicação acesse dados seus em outro serviço sem que você entregue a ela a sua senha.

A analogia clássica é a chave de manobrista. Ela liga o carro e permite estacionar, mas não abre o porta-malas nem o porta-luvas. O OAuth entrega à aplicação uma chave limitada: o token de acesso, com escopos que dizem o que ela pode fazer e por quanto tempo.

O ponto que desfaz a confusão: o OAuth diz o que a aplicação pode fazer, não quem você é. O token de acesso é feito para ser entendido pela API que o recebe. A aplicação cliente não deve interpretá-lo como prova de que alguém fez login.

Onde o OAuth se destaca:

  • Um aplicativo de agenda que lê seus eventos de outro serviço.

  • Uma integração entre dois sistemas que conversam por API.

  • Comunicação entre serviços, em que não há pessoa envolvida (fluxo client credentials). É aqui que o OAuth se encontra com as identidades não humanas, tema do nosso post anterior. Quando o workload roda em uma nuvem ou em um pipeline, a federação de identidade de workload (WIF) elimina até o segredo do cliente: o próprio workload apresenta um token OIDC e o troca por um token de acesso de curta duração. Esse tema merece um texto próprio, que virá em breve.


OIDC: a camada de identidade sobre o OAuth

Como as aplicações precisavam saber quem entrou, e o OAuth não dizia isso, surgiu o OpenID Connect. O OIDC é uma camada fina em cima do OAuth 2.0 que acrescenta o que faltava: o ID token.

O ID token é um JWT assinado que afirma quem é o usuário, quem o autenticou, para qual aplicação foi emitido e quando. Junto vêm o escopo openid e o endpoint de informações do usuário (UserInfo). O mecanismo de descoberta (/.well-known/openid-configuration) permite que a aplicação encontre sozinha as chaves e endereços do provedor.

Resumo prático: OIDC é o que você quer quando diz "entrar com a conta Google, Microsoft ou corporativa" em um aplicativo web ou móvel. Ele usa o OAuth por baixo, mas entrega o que o login precisa.


SAML 2.0: o padrão corporativo que ainda persiste

O SAML 2.0 (OASIS, 2005) é anterior ao OIDC e resolve o mesmo problema de fundo, federar a identidade, usando XML. O provedor de identidade (IdP) emite uma asserção assinada dizendo "esta pessoa foi autenticada e tem estes atributos", e o provedor de serviço (SP) confia nela.

Por que ainda existe, se é mais antigo e mais extenso?

  • Uma enorme base de sistemas corporativos e SaaS foi construída com SAML e o suporta de forma madura.

  • Contratos e auditorias já o citam.

  • Trocar o que funciona raramente é prioridade.

Para aplicações novas, o OIDC costuma ser mais simples de implementar e mais adequado a aplicativos móveis e de página única. Para integrar um SaaS que só oferece SAML, o SAML é a resposta, e está tudo bem.


SCIM 2.0: provisionamento e desprovisionamento

O SCIM (System for Cross-domain Identity Management, RFCs 7642, 7643 e 7644) é diferente dos outros três. Ele não faz login. Ele é uma API padronizada para criar, atualizar e desativar contas e grupos entre sistemas.

Sem SCIM, o ciclo de vida da conta fica assim:

  • Alguém cria a conta no SaaS na mão, ou

  • A conta nasce no primeiro login (provisionamento just-in-time), sem atributos confiáveis e sem remoção automática.

O problema do segundo caso aparece na saída. Com SSO, o desligado perde o login corporativo, mas a conta continua existindo no SaaS, com seus dados, papéis e, às vezes, tokens e chaves de API. Com SCIM, o desligamento no diretório chega ao aplicativo e a conta é desativada, normalmente pelo atributo active=false.

Vale um alerta: SCIM desativa a conta, mas não necessariamente encerra sessões nem revoga tokens já emitidos. Por isso o tempo de vida dos tokens importa tanto quanto o provisionamento.


Tabela de decisão

Situação

Use

Observação

Login em aplicativo web ou móvel novo

OIDC

Fluxo de código com PKCE

Integrar um SaaS corporativo que só aceita SSO por SAML

SAML 2.0

Valide a assinatura e restrinja os destinatários

Aplicação acessa uma API em nome do usuário

OAuth 2.0

Escopos mínimos

Serviço chama outro serviço, sem pessoa

OAuth 2.0 (client credentials)

Prefira credencial temporária ou federada

Criar e remover contas automaticamente a partir do RH ou do diretório

SCIM 2.0

Complementa o SSO, não o substitui

SSO e ciclo de vida completo em um SaaS

OIDC ou SAML + SCIM

Login e provisionamento são problemas separados


A regra de ouro: autenticação e provisionamento caminham juntos, mas nunca são o mesmo protocolo. Um ambiente maduro costuma ter SSO (OIDC ou SAML) para a entrada e SCIM para o ciclo de vida.


Erros comuns

  • Usar o token de acesso do OAuth como prova de login. Se a aplicação aceita qualquer token como prova de identidade, um token emitido para outra aplicação pode ser reaproveitado. Use o ID token do OIDC e valide emissor, destinatário (aud), validade e nonce.

  • Tokens com vida longa. Evite tokens de longa duração. Um token válido por semanas é um risco desnecessário de segurança. Adote tokens de acesso de curta duração combinados com refresh tokens com rotação.

  • URI de redirecionamento. Evite URIs de redirecionamento abertas ou com uso de wildcards. Permitir qualquer endereço de retorno possibilita que atacantes desviem o código de autorização para domínios maliciosos. Cadastre sempre as URIs exatas permitidas.

  • Escopos amplos "para funcionar". Pedir acesso total quando a aplicação lê um só recurso amplia o dano de qualquer vazamento.

  • Fluxos antigos. O fluxo implícito e o de senha do proprietário do recurso estão desaconselhados nas recomendações atuais de segurança do OAuth (RFC 9700). Use código de autorização com PKCE.

  • Não validar a assinatura do SAML. Aceitar asserções sem validar a assinatura, ou validar o trecho errado do documento, é uma falha clássica de integração.

  • SSO sem SCIM. O login corporativo é desativado no desligamento, mas a conta, e o que ela acessa, continuam vivos no aplicativo.

  • Considerar que "tem SSO" significa "está seguro". SSO centraliza o risco: o provedor de identidade passa a ser o alvo, e merece MFA resistente a phishing e monitoramento. 


Checklist rápido para o seu próximo projeto

  1. Escreva em uma frase qual problema você está resolvendo: autorizar, autenticar, federar ou provisionar.

  2. Para login novo, parta de OIDC. Para SaaS legado, aceite SAML.

  3. Defina escopos mínimos e vida curta para os tokens.

  4. Cadastre as URIs de redirecionamento exatas.

  5. Valide os tokens e asserções recebidos (emissor, destinatário, validade, assinatura).

  6. Habilite SCIM sempre que o aplicativo oferecer, e teste o desligamento de ponta a ponta.

  7. Inclua serviços e integrações no inventário. Todo cliente OAuth é uma identidade com dono.


Conclusão

OAuth autoriza, OIDC autentica, SAML federa e SCIM provisiona. Quando você começa pela pergunta certa, a escolha deixa de ser uma disputa de siglas e vira uma decisão de arquitetura. O erro mais caro do mercado continua sendo o mesmo: tratar o OAuth como login e esquecer o ciclo de vida da conta.

Esse tema faz parte da disciplina Autenticação, SSO e Federação da nossa pós-graduação. Para receber os próximos conteúdos, assine a newsletter e conheça a grade da pós. No próximo texto, falamos de identidade de agentes de IA: quem é o agente e em nome de quem ele age, que é, no fundo, uma pergunta de delegação OAuth.


Referências



Comentários

bottom of page