Quando diferentes sistemas corporativos precisam trocar informações, as APIs corporativas funcionam como pontes entre aplicações, bancos de dados e serviços. O problema surge quando essa comunicação depende de credenciais de usuários compartilhadas, armazenadas em aplicações ou transmitidas entre diferentes componentes da arquitetura.

Esse modelo pode ampliar a superfície de ataque e dificultar o controle sobre quem acessou determinado recurso. Uma arquitetura moderna deve buscar o contrário: o usuário autentica sua identidade, enquanto os sistemas trocam credenciais técnicas e tokens com escopo e permissões controlados.

É nesse contexto que entram OAuth 2.0, tokens de acesso, autenticação entre serviços, controle de escopos e mecanismos de autorização. O objetivo é permitir que sistemas corporativos se comuniquem sem transformar senhas e credenciais dos usuários em “chaves universais” espalhadas pela infraestrutura.

Por que proteger a autorização entre APIs corporativas?

Uma API pode conectar sistemas extremamente diferentes: ERP, CRM, plataformas financeiras, sistemas de RH, aplicações próprias, serviços de parceiros e bancos de dados.

Quando uma aplicação precisa acessar outra, surge uma pergunta fundamental:

Como provar que aquela aplicação está autorizada a executar determinada ação sem entregar a ela a senha do usuário?

Uma solução inadequada pode levar a situações como:

• senhas armazenadas em aplicações;
• credenciais compartilhadas entre sistemas;
• tokens com permissões excessivas;
• chaves expostas em código-fonte;
• credenciais transmitidas desnecessariamente;
• ausência de rotação de segredos;
• dificuldade para revogar acessos;
• falta de rastreabilidade.

O OWASP API Security Project destaca riscos específicos relacionados à segurança de APIs. Entre eles estão falhas de autenticação, falhas de autorização em nível de objeto e função, configurações inseguras e consumo inseguro de APIs.

Uma API segura não deve apenas verificar quem está fazendo uma requisição. Ela precisa verificar também o que essa identidade está autorizada a fazer.

Autenticação e autorização: qual é a diferença?

Embora frequentemente apareçam juntas, autenticação e autorização são conceitos diferentes.

Autenticação responde: “Quem é você?”

Autorização responde: “O que você pode fazer?”

Imagine um colaborador acessando um sistema corporativo.

Primeiro, a identidade do usuário precisa ser autenticada.

Depois, o sistema deve determinar quais recursos esse usuário pode consultar ou modificar.

Em uma arquitetura integrada, essa distinção pode ser representada assim:

usuário → autenticação → aplicação → autorização → API → recurso

Esse modelo ajuda a evitar que uma aplicação precise conhecer a senha do usuário para acessar outro serviço.

As diretrizes atuais do NIST SP 800-63-4 tratam de identidade digital, autenticação e federação, oferecendo requisitos e recomendações para esses processos. A publicação foi finalizada em 2025 e substituiu a versão anterior SP 800-63-3.

O que é OAuth 2.0 e por que ele é importante para APIs?

O OAuth 2.0 é um framework de autorização que permite a uma aplicação obter acesso limitado a um serviço HTTP sem precisar receber diretamente as credenciais do proprietário do recurso.

O RFC 6749, publicado pela IETF, define o framework OAuth 2.0 e seus principais papéis, incluindo proprietário do recurso, cliente, servidor de autorização e servidor de recursos.

Em uma arquitetura corporativa, isso permite separar responsabilidades.

Por exemplo:

Usuário → sistema de identidade → token → aplicação → API

Em vez de transmitir a senha do usuário para cada serviço, a aplicação recebe um token que representa uma autorização específica.

Esse token pode carregar informações como:

• identidade associada;
• escopos;
• audiência;
• prazo de validade;
• emissor;
• outras informações necessárias à validação.

A ideia central é substituir o compartilhamento indiscriminado de credenciais por autorizações delimitadas.

Como funciona um fluxo seguro de autorização?

Um fluxo corporativo pode funcionar de maneira simplificada da seguinte forma:

1. O usuário autentica sua identidade

O usuário acessa a aplicação utilizando o mecanismo corporativo de autenticação.

Essa etapa pode envolver autenticação multifator, identidade federada ou outros mecanismos adequados ao ambiente.

2. A aplicação solicita autorização

A aplicação solicita ao servidor de autorização um token compatível com o recurso que precisa acessar.

3. O servidor de autorização valida o contexto

São avaliados elementos como:

• identidade;
• aplicação;
• permissões;
• escopo;
• audiência;
• política de acesso;
• validade da autorização.

4. O token é emitido

O servidor de autorização fornece um token de acesso com as permissões correspondentes.

5. A aplicação chama a API

A aplicação apresenta o token ao serviço que protege o recurso.

6. A API valida o token

O servidor de recursos verifica se o token:

• é válido;
• está dentro do prazo;
• foi emitido por uma autoridade confiável;
• é destinado ao serviço correto;
• possui os escopos necessários.

7. A API executa somente a operação autorizada

Se as condições forem atendidas, o serviço processa a requisição.

O usuário não precisa entregar sua senha à API de destino.

O que mudou nas boas práticas de OAuth 2.0?

É importante observar que OAuth 2.0 não deve ser implementado apenas com base em documentos antigos.

Em janeiro de 2025, a IETF publicou o RFC 9700 — OAuth 2.0 Security Best Current Practice, atualizando e ampliando as recomendações de segurança do OAuth 2.0. O documento também desaconselha ou descontinua determinados modos de operação considerados menos seguros.

Entre as recomendações do RFC 9700 estão mecanismos como:

• uso de PKCE em cenários aplicáveis;
• restrição de privilégios dos tokens;
• proteção contra reutilização de tokens;
• autenticação adequada do cliente;
• uso de TLS;
• mecanismos para limitar o impacto de tokens roubados;
• preferência por métodos robustos de autenticação de clientes.

A IETF recomenda, por exemplo, mecanismos de sender-constrained access tokens, como mTLS ou DPoP, para reduzir o risco de utilização indevida de tokens de acesso roubados ou vazados.

Isso é particularmente relevante em arquiteturas corporativas com múltiplas APIs e integrações críticas.

Como evitar que credenciais de usuários sejam expostas?

Uma das principais decisões arquiteturais é separar credenciais humanas de credenciais utilizadas por serviços.

Uma aplicação não deveria precisar armazenar a senha de um usuário simplesmente porque precisa consultar uma API.

Em seu lugar, podem ser utilizados mecanismos como:

• tokens de acesso;
• OAuth 2.0;
• autenticação de cliente;
• identidade federada;
• mTLS;
• JWT, quando adequado;
• gestão centralizada de segredos;
• escopos de autorização.

O NIST SP 800-63B-4, publicado em 2025, estabelece orientações atualizadas para autenticação e gerenciamento de autenticadores, incluindo requisitos relacionados à autenticação digital e à gestão desses mecanismos.

A arquitetura deve garantir que cada componente receba somente a credencial ou autorização necessária para cumprir sua função.

Princípio do menor privilégio aplicado às APIs

Um dos conceitos mais importantes em segurança de APIs é o menor privilégio.

Isso significa conceder apenas as permissões necessárias para determinada tarefa.

Imagine uma API financeira que oferece:

• consultar saldo;
• consultar transações;
• criar pagamento;
• cancelar pagamento;
• administrar usuários.

Uma integração que precisa apenas consultar transações não deveria receber autorização para administrar usuários.

Uma política de autorização pode estabelecer, por exemplo:

API A → consultar transações

e não:

API A → acesso total ao sistema financeiro

Essa diferença reduz o impacto potencial caso uma credencial, token ou aplicação seja comprometida.

O OWASP API Security Top 10 inclui riscos relacionados a autorização em nível de objeto e função, reforçando que a segurança precisa considerar não apenas o acesso à API, mas também quais recursos e funções cada consumidor pode utilizar.

Tokens de acesso devem ter escopo e validade controlados

Um erro comum é tratar o token como se fosse uma senha permanente.

O token deve representar uma autorização controlada.

Entre os mecanismos que podem ser considerados estão:

• escopos específicos;
• tempo de validade limitado;
• audiência definida;
• emissor confiável;
• rotação;
• revogação quando aplicável;
• validação de assinatura;
• restrição de uso.

O RFC 9700 recomenda que os privilégios associados a um token de acesso sejam restritos e também apresenta mecanismos para reduzir o risco de reutilização de tokens roubados.

Quanto menor a janela de exposição e menor o privilégio associado ao token, menor tende a ser o impacto potencial de seu comprometimento.

Client Credentials: quando uma API precisa falar com outra API

Nem toda comunicação entre APIs ocorre em nome de um usuário.

Imagine:

Sistema de faturamento → API de emissão fiscal

Nesse caso, não necessariamente existe uma pessoa realizando uma ação naquele momento.

É uma comunicação serviço a serviço.

Para esses cenários, o OAuth 2.0 possui mecanismos apropriados para autenticação de clientes e obtenção de tokens em nome da própria aplicação.

O RFC 9700 recomenda autenticação de cliente quando viável e aponta métodos baseados em criptografia assimétrica, como mTLS e private_key_jwt, como opções robustas para autenticação de clientes.

A arquitetura pode ficar assim:

Serviço A → servidor de autorização → token → Serviço B

Dessa maneira, o Serviço A não precisa conhecer a senha de nenhum usuário do Serviço B.

JWT é suficiente para proteger uma API?

Não.

JWT é um formato de token, não uma estratégia completa de segurança.

Um JWT pode transportar informações sobre uma autorização, mas a segurança depende de como ele é:

• emitido;
• assinado;
• validado;
• transportado;
• armazenado;
• expirado;
• revogado ou substituído;
• utilizado pelo serviço receptor.

O OWASP recomenda, no contexto de autenticação, validar elementos como audiência, emissor e escopos quando aplicável.

Portanto, simplesmente adicionar um JWT ao cabeçalho de uma requisição não transforma automaticamente uma API em uma API segura.

Como armazenar credenciais técnicas com segurança?

Outro ponto crítico está nas credenciais utilizadas pelos próprios serviços.

Nunca é recomendável espalhar chaves e segredos diretamente pelo código-fonte.

Uma arquitetura mais segura pode utilizar um gerenciador de segredos, mantendo credenciais fora da aplicação e controlando seu acesso.

A gestão deve considerar:

• armazenamento protegido;
• controle de acesso;
• rotação;
• expiração;
• auditoria;
• segregação por ambiente;
• revogação;
• princípio do menor privilégio.

O OWASP Top 10 de 2025 inclui credenciais codificadas diretamente (hard-coded credentials) entre os problemas associados a falhas de autenticação.

Se uma chave está gravada no código, em um repositório ou em uma configuração sem proteção adequada, ela pode se tornar um alvo muito mais fácil para exposição acidental ou maliciosa.

API Gateway: uma camada estratégica de proteção

Em arquiteturas com muitas APIs, um API Gateway pode funcionar como uma camada central para determinadas funções de segurança e governança.

Dependendo da arquitetura, ele pode ajudar a:

• autenticar requisições;
• validar tokens;
• aplicar políticas;
• controlar tráfego;
• limitar requisições;
• registrar eventos;
• direcionar chamadas;
• ocultar detalhes internos;
• aplicar regras de acesso.

Isso não significa que o gateway sozinho resolva todos os problemas.

A autorização também precisa existir no serviço que protege o recurso, especialmente quando diferentes usuários e aplicações possuem diferentes níveis de acesso.

O OWASP destaca riscos como autorização quebrada em nível de objeto e função, mostrando por que a validação não deve depender exclusivamente de uma única camada.

mTLS: proteção adicional para comunicação entre serviços

O Mutual TLS (mTLS) amplia o modelo tradicional de TLS ao permitir autenticação dos dois lados da conexão.

Em uma comunicação entre sistemas críticos, isso pode ajudar a garantir que tanto o cliente quanto o servidor apresentem certificados válidos.

O RFC 9700 cita mTLS como um mecanismo de sender constraint para tokens e também como método recomendado de autenticação de clientes em determinados cenários.

Uma arquitetura pode combinar:

TLS → autenticação do cliente → OAuth → token → autorização → API

Cada camada desempenha uma função diferente.

Como projetar um fluxo seguro entre APIs corporativas?

Uma arquitetura corporativa pode seguir este modelo:

Usuário → Identidade Corporativa → Aplicação → Authorization Server → Access Token → API Gateway → API de destino → Sistema

Cada componente possui uma responsabilidade.

Identidade corporativa

Responsável por autenticar o usuário.

Authorization Server

Responsável por emitir autorizações e tokens conforme as políticas estabelecidas.

Aplicação

Utiliza a autorização recebida para solicitar acesso aos recursos necessários.

API Gateway

Pode aplicar políticas, validar tokens e controlar o tráfego.

API de destino

Valida a autorização e executa somente a operação permitida.

Sistema de origem

Mantém o recurso protegido e as regras de negócio.

Essa separação reduz a necessidade de compartilhar credenciais humanas entre diferentes sistemas.

O que não fazer em uma arquitetura de APIs

Algumas práticas devem ser evitadas.

Não compartilhe senhas de usuários entre sistemas

Isso dificulta a revogação e aumenta a exposição das credenciais.

Não coloque chaves no código

Credenciais devem ser gerenciadas fora do código e protegidas adequadamente.

Não use um único token para tudo

Diferentes serviços e operações devem ter permissões apropriadas.

Não conceda privilégios administrativos sem necessidade

O menor privilégio deve orientar a arquitetura.

Não ignore a expiração dos tokens

Credenciais permanentes aumentam a janela de exposição.

Não confie apenas no gateway

A API de destino também precisa aplicar suas próprias regras de autorização.

Não registre tokens em logs

Logs devem ser desenhados para fornecer rastreabilidade sem transformar informações de autenticação em novos pontos de exposição.

Como implementar autorização segura entre APIs: passo a passo

Uma estratégia prática pode seguir estas etapas:

1. Mapeie os fluxos de dados

Identifique:

• quem chama;
• quem recebe;
• qual dado é acessado;
• qual operação é realizada;
• em nome de quem a operação ocorre.

2. Separe usuários de serviços

Determine quais fluxos representam uma ação de usuário e quais são exclusivamente comunicação entre sistemas.

3. Defina os níveis de autorização

Crie escopos e permissões específicos para cada operação.

4. Escolha o mecanismo de autenticação

Avalie OAuth 2.0, autenticação de cliente, mTLS, federação e outros mecanismos conforme o cenário.

5. Centralize a emissão de tokens

Evite que cada aplicação implemente sua própria lógica de emissão e validação de credenciais quando uma arquitetura centralizada for apropriada.

6. Proteja os segredos

Utilize mecanismos apropriados para armazenar e rotacionar credenciais técnicas.

7. Proteja o transporte

Utilize TLS e, quando necessário, mecanismos adicionais como mTLS.

O RFC 9700 recomenda o uso de TLS ponta a ponta entre cliente e servidor de recursos.

8. Registre e monitore

Acompanhe:

• autenticações;
• autorizações;
• falhas;
• chamadas;
• alterações de permissões;
• emissão e uso de tokens;
• comportamentos anômalos.

9. Teste os controles

Testes devem verificar não apenas se usuários autorizados conseguem acessar recursos, mas também se usuários ou aplicações sem autorização são efetivamente impedidos.

Como a Cortex pode ajudar na integração segura de APIs?

A integração entre sistemas corporativos é uma das áreas em que arquitetura e segurança precisam caminhar juntas.

Não basta fazer duas aplicações “conversarem”.

É necessário estabelecer quem pode chamar, o que pode consultar, quais dados podem trafegar, por quanto tempo a autorização é válida e como cada operação será rastreada.

A Cortex Soluções Corporativas Inteligentes pode apoiar organizações na construção de integrações entre sistemas e APIs, estruturando fluxos de comunicação capazes de conectar aplicações corporativas sem transformar credenciais de usuários em dependências desnecessárias.

Essa abordagem pode ser especialmente relevante em ambientes que envolvem:

• ERP;
• CRM;
• sistemas financeiros;
• plataformas de RH;
• bancos de dados;
• sistemas legados;
• aplicações próprias;
• serviços de parceiros;
• APIs internas e externas.

Integração segura não é simplesmente conectar sistemas. É criar uma comunicação controlada, rastreável e alinhada às regras de acesso da organização.

Checklist de segurança para autorização entre APIs

Antes de colocar uma integração em produção, avalie:

• A senha do usuário é evitada na comunicação entre sistemas?

• A autenticação está separada da autorização?

• Cada API possui permissões adequadas?

• Os tokens possuem escopo definido?

• Os tokens possuem validade apropriada?

• A audiência do token é validada?

• O emissor do token é validado?

• As credenciais técnicas são armazenadas em local seguro?

• Existe rotação de segredos?

• A comunicação utiliza TLS?

• mTLS é necessário para algum fluxo crítico?

• A proteção contra reutilização indevida de tokens?

• As APIs aplicam autorização no nível dos recursos?

• Existe monitoramento das chamadas?

• Os logs evitam armazenar credenciais e tokens?

• Existe processo de revogação?

• As permissões seguem o princípio do menor privilégio?

Conclusão: segurança começa antes da primeira chamada da API

Implementar fluxos seguros de autorização entre APIs corporativas exige muito mais do que adicionar uma chave ou um token às requisições.

Uma arquitetura robusta separa autenticação e autorização, evita o compartilhamento de senhas, restringe privilégios, protege credenciais técnicas e utiliza mecanismos adequados para controlar a comunicação entre aplicações.

O OAuth 2.0 continua sendo uma das principais bases para autorização de APIs, mas suas implementações devem considerar as recomendações atuais do RFC 9700 da IETF, especialmente em relação à proteção de tokens, autenticação de clientes, PKCE, restrição de privilégios e segurança do transporte.

Ao mesmo tempo, as recomendações do NIST e os riscos identificados pelo OWASP API Security Project reforçam que identidade, autenticação, autorização e governança precisam ser tratados como partes de uma mesma estratégia de segurança.

Para a empresa, o resultado é mais do que proteger credenciais.

É criar uma arquitetura de integração na qual sistemas possam compartilhar informações e executar processos sem ampliar desnecessariamente os privilégios ou expor as credenciais dos usuários.

A Cortex pode ajudar sua organização a estruturar integrações, APIs e fluxos de comunicação corporativos com uma arquitetura orientada a segurança, controle e eficiência.

Quer avaliar como tornar suas integrações entre APIs mais seguras e eliminar o compartilhamento desnecessário de credenciais? Conheça as soluções da Cortex e converse com nossa equipe.

Se este conteúdo foi útil, compartilhe com profissionais de TI, arquitetura, segurança da informação e desenvolvimento que trabalham com integração de sistemas e APIs corporativas.