Open Authorization.

Os quatro principais OAuth 2.0 Flows.

Wagner Iatalessi do Valle
5 min readSep 29, 2024

Authorization Code Flow

Como o Authorization Code Flow Funciona em um CIAM.

O Authorization Code Flow é o mais seguro e amplamente utilizado quando se trata de autenticar usuários via OAuth 2.0. Este fluxo envolve uma troca intermediária de um “authorization code” antes de o cliente obter o token de acesso. Ele é ideal para aplicativos da web que possuem um backend seguro, pois evita a exposição direta do token de acesso.

Quando usar?

  • Quando você está construindo uma aplicação web segura.
  • Quando quer minimizar o risco de exposição dos tokens de acesso.
  • Quando o seu app pode armazenar segredos de cliente de maneira segura.

Passos no CIAM com OAuth Server:

  1. Solicitação do Authorization Code: O usuário acessa um serviço e o app redireciona o usuário para o servidor OAuth/CIAM para que ele se autentique.
  2. Autenticação: O CIAM solicita as credenciais do usuário (login e senha ou outros métodos de autenticação).
  3. Autorização: Após a autenticação bem-sucedida, o CIAM emite um authorization code e redireciona o usuário de volta ao aplicativo cliente.
  4. Troca de Código: O app backend troca o authorization code por um access token no OAuth server.
  5. Acesso ao Recurso: Com o access token, o app faz requisições autenticadas à API, acessando dados protegidos do usuário.

Por que funciona bem?

Esse fluxo protege o token de acesso ao garantir que ele só seja trocado em uma comunicação segura entre o servidor OAuth e o backend da aplicação.

Client Credentials Flow

Client Credentials Flow — Autenticação sem o Usuário no CIAM

O que é?

O Client Credentials Flow é utilizado quando uma aplicação precisa acessar seus próprios recursos protegidos sem a interação direta de um usuário. Nesse caso, o aplicativo usa suas credenciais (ID e segredo do cliente) para autenticar diretamente com o OAuth Server.

Quando usar?

  • Quando você tem serviços back-to-back.
  • Quando sua aplicação precisa de acesso a recursos sem a presença de um usuário.

Passos no CIAM com OAuth Server:

  1. Autenticação do Cliente: A aplicação cliente envia suas credenciais (ID e segredo) diretamente para o servidor OAuth.
  2. Emissão do Token: O servidor CIAM/OAuth valida as credenciais e emite um access token.
  3. Acesso ao Recurso: A aplicação usa o access token para acessar recursos protegidos em nome de si mesma.

Por que funciona bem?

Esse fluxo elimina a necessidade de envolver um usuário em serviços de backend, automações, ou quando você precisa garantir que sua aplicação faça chamadas seguras a APIs sem expor credenciais sensíveis.

Implicit Code Flow

Implicit Code Flow — Simplicidade com Riscos para Apps Web no CIAM

O que é?

O Implicit Code Flow foi projetado para aplicativos que não possuem um backend seguro (por exemplo, Single Page Applications — SPAs). Em vez de trocar um authorization code por um access token, o token é retornado diretamente no redirecionamento após a autenticação do usuário.

Quando usar?

  • Quando está criando uma Single Page Application (SPA).
  • Quando não é possível armazenar segredos de cliente de forma segura no backend.

Passos no CIAM com OAuth Server:

  1. Solicitação de Autenticação: O usuário é redirecionado ao servidor CIAM/OAuth para autenticação.
  2. Emissão de Token Direto: Após a autenticação, o servidor OAuth retorna diretamente um access token ao cliente via o redirecionamento do navegador.
  3. Acesso ao Recurso: A aplicação usa o access token diretamente nas chamadas à API.

Por que funciona bem?

Funciona para aplicações sem backend, como SPAs, onde o armazenamento seguro de segredos de cliente não é possível. No entanto, esse fluxo está sendo gradualmente substituído por fluxos mais seguros (como Authorization Code Flow com PKCE).

Resource Owner Password Flow

Resource Owner Password Flow — O Caminho Rápido, Mas Arriscado no CIAM

O que é?

O Resource Owner Password Flow permite que as credenciais do usuário (usuário e senha) sejam enviadas diretamente ao cliente, que então as usa para obter um access token. Embora seja simples, esse método é menos seguro, pois expõe as credenciais do usuário diretamente à aplicação cliente.

Quando usar?

  • Quando a aplicação e o OAuth server têm uma alta confiança mútua.
  • Quando precisa de um processo de login simplificado para sistemas de legado.
  • Deve ser evitado em novos sistemas devido a questões de segurança.

Passos no CIAM com OAuth Server:

  1. Envio de Credenciais: O cliente coleta as credenciais (usuário e senha) diretamente do usuário e as envia ao CIAM/OAuth server.
  2. Emissão do Token: O OAuth server valida as credenciais e retorna um access token ao cliente.
  3. Acesso ao Recurso: O cliente usa o access token para acessar recursos protegidos.

Por que funciona bem?

Esse fluxo é eficiente para sistemas onde o cliente e o servidor já têm uma confiança pré-estabelecida. No entanto, é uma abordagem que expõe o usuário a maiores riscos, já que as credenciais passam diretamente pelo cliente.

Esses são os quatro principais OAuth 2.0 flows e como eles se aplicam no contexto de um CIAM com OAuth Server. Cada um tem seus prós e contras, sendo necessário escolher o fluxo que melhor se adapta à arquitetura e ao nível de segurança exigido pelo seu sistema.

Resumo:

  • Authorization Code Flow: Maior segurança e ideal para web apps com backend seguro.
  • Client Credentials Flow: Melhor para integração back-to-back.
  • Implicit Code Flow: Simples, mas com maior risco, principalmente para SPAs.
  • Resource Owner Password Flow: Evitar, a menos que seja absolutamente necessário.

Esses conceitos, quando aplicados a um CIAM, ajudam a oferecer uma autenticação robusta e personalizada para usuários e clientes em qualquer aplicação.

Referência das imagens: ByteByteGo.

--

--

Wagner Iatalessi do Valle
Wagner Iatalessi do Valle

Written by Wagner Iatalessi do Valle

Desenvolvi minha carreira na área da Tecnologia da Informação, atuando em empresas nacionais e multinacionais de grande porte nos segmentos de tecnologia.

No responses yet