Introdução
Se você desenvolve aplicações web, APIs ou sistemas distribuídos, já se deparou com a necessidade de responder a duas perguntas fundamentais: “quem é você?” (autenticação) e “o que você pode fazer?” (autorização). Esses dois conceitos são os pilares de qualquer sistema seguro, mas frequentemente geram confusão — especialmente quando entram em cena protocolos como OAuth2, OpenID Connect e tokens como JWT.
Neste artigo, vamos descomplicar esses conceitos de forma prática e didática. Você vai entender a diferença entre autenticação e autorização, como o JWT (JSON Web Token) funciona por dentro, o papel do OAuth 2.0 na delegação de acesso, e como o OpenID Connect adiciona a camada de identidade que faltava. Além disso, vamos explorar os tipos de Client ID que existem no Azure Entra ID (antigo Azure AD) e quando usar cada um para aplicações SPA, Server-Side e API REST.
Este conteúdo é voltado para desenvolvedores back-end, front-end e full-stack que desejam implementar autenticação e autorização de forma correta e segura. Se você trabalha com automação e integração de sistemas, este artigo também será útil — assim como entender as diferenças entre terminal e pipeline é relevante para contextos de execução, a segurança dos seus fluxos depende de compreender como identidades são gerenciadas. E se você já domina esses fundamentos e quer elevar a segurança da sua SPA ao próximo nível, confira BFF Backend For Frontend: Segurança em SPAs, onde aplicamos esses conceitos no padrão BFF.
Autenticação vs. Autorização: Qual a Diferença?
Antes de mergulharmos nos protocolos, é essencial entender a diferença entre esses dois conceitos que, apesar de relacionados, têm responsabilidades completamente distintas.
Autenticação (Authentication — AuthN) é o processo de verificar a identidade de um usuário ou sistema. É a resposta para a pergunta: “Você é quem diz ser?”. Quando você digita seu e-mail e senha em uma tela de login, está passando por um processo de autenticação. Outros exemplos incluem biometria, certificados digitais e tokens de acesso.
Autorização (Authorization — AuthZ) é o processo de verificar permissões. Após confirmar quem você é, o sistema precisa decidir: “O que você tem permissão para fazer?”. Um usuário autenticado pode ter acesso a determinados recursos, mas não a todos. Por exemplo, um desenvolvedor pode ter permissão para ler logs de produção, mas não para excluir bancos de dados.
| Aspecto | Autenticação (AuthN) | Autorização (AuthZ) |
|---|---|---|
| Pergunta | “Quem é você?” | “O que você pode fazer?” |
| Momento | Ocorre primeiro | Ocorre após a autenticação |
| Mecanismo | Login, senhas, tokens, biometria | Roles, claims, policies, escopos |
| Protocolo | OpenID Connect, SAML | OAuth 2.0 |
| Exemplo | Fazer login com e-mail e senha | Acessar o endpoint /admin da API |
ℹ️ Informação: Um erro muito comum é tratar OAuth 2.0 como um protocolo de autenticação. Na verdade, o OAuth 2.0 é um protocolo de autorização. Quem adiciona a camada de autenticação é o OpenID Connect, que é construído em cima do OAuth 2.0.
O que é JWT (JSON Web Token)?
O JWT (pronuncia-se “jot”) é um padrão aberto definido na RFC 7519 para transmitir informações de forma compacta e segura entre partes como um objeto JSON. Ele é amplamente utilizado como formato de token em fluxos de autenticação e autorização.
Estrutura de um JWT
Um JWT é composto por três partes separadas por pontos (.):
| |
- Header — contém o tipo do token e o algoritmo de assinatura.
- Payload — contém as claims (declarações) sobre a entidade e metadados.
- Signature — garante que o token não foi alterado.
Exemplo de JWT decodificado
Header:
| |
Payload:
| |
Claims importantes no contexto do Azure Entra ID
| Claim | Descrição |
|---|---|
iss | Emissor do token (issuer) — identifica o Azure Entra ID |
sub | Subject — identificador único do usuário |
aud | Audience — para qual aplicação/API o token foi emitido |
exp | Expiração do token (timestamp Unix) |
iat | Momento da emissão (issued at) |
roles | Roles atribuídas ao usuário na aplicação |
scp | Escopos delegados (scopes) — permissões concedidas |
tid | Tenant ID do Azure Entra |
oid | Object ID do usuário no diretório |
⚠️ Atenção: Nunca armazene informações sensíveis no payload de um JWT. O payload é codificado em Base64, mas não é criptografado — qualquer pessoa pode decodificá-lo. A assinatura garante apenas a integridade, não a confidencialidade. Se precisar de confidencialidade, utilize JWE (JSON Web Encryption) conforme a RFC 7516.
Validação de um JWT
Ao receber um JWT, sua aplicação DEVE validar:
- Assinatura — verificar com a chave pública do emissor (disponível no endpoint JWKS).
- Issuer (
iss) — confirmar que o emissor é o esperado. - Audience (
aud) — confirmar que o token foi emitido para sua API. - Expiração (
exp) — rejeitar tokens expirados. - Not Before (
nbf) — se presente, rejeitar tokens antes do horário permitido.
OAuth 2.0: O Protocolo de Autorização
O OAuth 2.0 é um framework de autorização definido na RFC 6749 que permite que aplicações obtenham acesso limitado a recursos de um usuário em um servidor, sem expor as credenciais do usuário à aplicação.
Os Quatro Papéis do OAuth 2.0
O protocolo define quatro papéis fundamentais:
- Resource Owner — o usuário que possui os dados (ex: o dono da conta).
- Client — a aplicação que quer acessar os dados em nome do usuário.
- Authorization Server — o servidor que autentica o usuário e emite tokens (ex: Azure Entra ID).
- Resource Server — a API que protege os recursos e valida os tokens.
Principais Fluxos (Grant Types)
O OAuth 2.0 define diversos fluxos para diferentes cenários. Cada tipo de aplicação utiliza o fluxo mais adequado à sua arquitetura:
| Fluxo | Cenário | Segurança |
|---|---|---|
| Authorization Code + PKCE | SPAs, apps mobile, apps web | Alta |
| Client Credentials | Comunicação servidor-a-servidor (M2M) | Alta |
| On-Behalf-Of (OBO) | APIs chamando outras APIs em nome do user | Alta |
| Device Code | Dispositivos sem navegador (IoT, CLI) | Média |
⚠️ Atenção: Os fluxos Implicit e Resource Owner Password Credentials (ROPC) são considerados obsoletos e inseguros. A recomendação da IETF e da Microsoft é utilizar Authorization Code com PKCE para todas as aplicações públicas (SPAs e mobile).
O Fluxo Authorization Code com PKCE
Este é o fluxo recomendado para a maioria das aplicações modernas. Veja o passo a passo:
- O Client gera um
code_verifier(string aleatória) e umcode_challenge(hash SHA-256 do verifier). - O Client redireciona o usuário para o Authorization Server com o
code_challenge. - O usuário se autentica e consente o acesso.
- O Authorization Server retorna um authorization code para o Client.
- O Client troca o authorization code +
code_verifierpor um access token. - O Client usa o access token para acessar o Resource Server (API).
| |
OpenID Connect: Identidade sobre OAuth 2.0
O OpenID Connect (OIDC) é uma camada de identidade construída sobre o OAuth 2.0. Enquanto o OAuth 2.0 responde “o que você pode acessar?”, o OIDC responde “quem é você?”.
O OIDC introduz um novo tipo de token: o ID Token. Esse token é um JWT que contém informações sobre o usuário autenticado (nome, e-mail, foto, etc.) e é emitido junto com o access token.
Diferença entre os Tokens
| Token | Propósito | Formato | Quem consome? |
|---|---|---|---|
| ID Token | Informações de identidade do usuário | JWT | O Client (front-end) |
| Access Token | Autorização para acessar recursos protegidos | JWT* | O Resource Server |
| Refresh Token | Obter novos access tokens sem reautenticar | Opaco | O Authorization Server |
ℹ️ Informação: O Access Token emitido pelo Azure Entra ID é um JWT, mas a especificação do OAuth 2.0 não obriga esse formato — alguns provedores usam tokens opacos. Sempre valide o token conforme a documentação do seu provedor.
Escopos do OpenID Connect
O OIDC define escopos padronizados que determinam quais informações do usuário são retornadas:
openid— obrigatório para ativar o fluxo OIDC; retorna o claimsub.profile— retornaname,family_name,given_name,picture, etc.email— retornaemaileemail_verified.offline_access— solicita um refresh token para renovação do acesso.
Tipos de Client ID no Azure Entra ID
No Azure Entra ID, ao registrar uma aplicação, você obtém um Client ID (também chamado de Application ID). Porém, o tipo de registro e a configuração da plataforma variam conforme a natureza da aplicação. Isso afeta diretamente o fluxo OAuth utilizado e o nível de segurança.
Aplicação Pública vs. Confidencial
O Azure Entra ID classifica as aplicações em dois tipos fundamentais:
| Tipo | Pode guardar segredo? | Exemplos | Fluxos recomendados |
|---|---|---|---|
| Pública | Não | SPA, mobile, desktop, CLI | Authorization Code + PKCE |
| Confidencial | Sim | Web app server-side, daemon, API | Auth Code + Secret, Client Credentials |
💡 Dica: Uma aplicação é pública quando executa em um ambiente que o usuário controla (navegador, celular, desktop) — onde não é possível armazenar um segredo com segurança. Uma aplicação é confidencial quando executa em um servidor que você controla.
1. Client ID para Aplicações SPA (Single Page Application)
Uma SPA (Single Page Application) é uma aplicação front-end que roda inteiramente no navegador, como aplicações React, Angular ou Vue.js. Como o código é executado no lado do cliente, não é possível armazenar Client Secrets — qualquer segredo seria exposto no código-fonte ou nas ferramentas de desenvolvedor do navegador.
Configuração no Azure Entra ID:
- Tipo de plataforma: Single-page application
- Tipo de aplicação: Public client
- Redirect URI:
http://localhost:4200(dev) /https://app.seudominio.com(produção) - Fluxo OAuth: Authorization Code com PKCE
- Client Secret: NÃO usar — aplicações públicas não devem ter secret
Registro via Azure CLI:
| |
Exemplo com Angular 16+ e @azure/msal-angular:
Primeiro, instale as dependências necessárias:
| |
Configuração do MSAL (auth-config.ts):
| |
Módulo principal com standalone API (app.config.ts):
| |
Rotas protegidas (app.routes.ts):
| |
Componente com login e chamada à API (home.component.ts):
| |
💡 Dica: No Angular 16+, o
MsalInterceptorinjeta automaticamente o access token em todas as requisições HTTP que correspondam aos padrões configurados noprotectedResourceMap. Você não precisa gerenciar tokens manualmente — basta usar oHttpClientnormalmente.
ℹ️ Informação: Embora o MSAL funcione bem para SPAs, a abordagem mais segura atualmente é o padrão BFF (Backend For Frontend), que evita expor tokens no navegador. Veja a implementação completa em BFF Backend For Frontend: Segurança em SPAs.
2. Client ID para Aplicações Server-Side (Web App)
Aplicações server-side são aplicações web tradicionais que executam no servidor (ex: ASP.NET, Django, Express.js). Como o código roda em um ambiente controlado, essas aplicações podem armazenar um Client Secret com segurança.
Configuração no Azure Entra ID:
- Tipo de plataforma: Web
- Tipo de aplicação: Confidential client
- Redirect URI:
https://app.seudominio.com/auth/callback - Fluxo OAuth: Authorization Code (com Client Secret)
- Client Secret: Sim — armazenado de forma segura no servidor (ex: variável de ambiente, Key Vault)
Registro via Azure CLI:
| |
Exemplo com Python (Flask + MSAL):
| |
⚠️ Atenção: Nunca exponha o Client Secret no código-fonte, repositórios Git ou logs. Utilize variáveis de ambiente, Azure Key Vault ou ferramentas de gerenciamento de segredos. No exemplo acima, os valores vêm de
os.environpor segurança.
3. Client ID para APIs REST (Comunicação Machine-to-Machine)
Quando uma API backend ou serviço daemon precisa acessar outra API protegida sem interação de um usuário, utiliza-se o fluxo Client Credentials. Neste cenário, a própria aplicação se autentica com seu Client ID e Client Secret (ou certificado), sem envolver nenhum usuário.
Configuração no Azure Entra ID:
- Tipo de plataforma: Nenhuma (não precisa de Redirect URI)
- Tipo de aplicação: Confidential client
- Fluxo OAuth: Client Credentials
- Client Secret ou Certificado: Sim — obrigatório
- Permissões: Application permissions (não delegadas)
Cenários comuns:
- Cronjobs e serviços agendados que consomem APIs
- Microsserviço A chamando Microsserviço B
- Pipelines de CI/CD que acessam recursos protegidos
- Daemons e workers em background
Exemplo com Python (requests + MSAL):
| |
💡 Dica: Para cenários de produção com alta segurança, prefira certificados em vez de Client Secrets para autenticação de serviços M2M. Certificados oferecem maior segurança e podem ser gerenciados via Azure Key Vault.
Tabela Comparativa: Qual Tipo de Client ID Usar?
Esta tabela resume as decisões que você precisa tomar ao registrar sua aplicação no Azure Entra ID:
| Característica | SPA (Public Client) | Server-Side (Confidential) | API REST / Daemon (Confidential) |
|---|---|---|---|
| Onde executa | Navegador do usuário | Servidor web | Servidor backend |
| Client Secret | Não | Sim | Sim (ou certificado) |
| Fluxo OAuth | Auth Code + PKCE | Auth Code + Secret | Client Credentials |
| Interação do usuário | Sim (login interativo) | Sim (login interativo) | Não (M2M) |
| Tokens recebidos | ID Token + Access Token | ID Token + Access Token | Apenas Access Token |
| Refresh Token | Sim (com offline_access) | Sim | Não (usa cache de token) |
| Exemplo de app | Angular, React, Vue | Flask, ASP.NET, Express | Cronjob, microsserviço, daemon |
| Plataforma no portal | Single-page application | Web | Nenhuma (só permissões de app) |
| Biblioteca MSAL | @azure/msal-angular | msal-python / MSAL.NET | msal-python / MSAL.NET |
Protegendo Sua API com C#: Validação de Tokens no ASP.NET Core
Independentemente de qual tipo de client chama sua API, a API REST precisa validar o access token recebido. Veja como fazer isso em C# com ASP.NET Core usando o pacote Microsoft.Identity.Web, que é a forma recomendada pela Microsoft para proteger APIs com Azure Entra ID.
Primeiro, crie o projeto e instale as dependências:
| |
Configuração (appsettings.json):
| |
Configuração do Program.cs:
| |
Controller com endpoints protegidos (DadosController.cs):
| |
💡 Dica: O pacote
Microsoft.Identity.Websimplifica enormemente a validação de tokens no ASP.NET Core. Ele busca automaticamente as chaves JWKS do Azure Entra ID, valida issuer, audience, assinatura e expiração — tudo configurado com apenas uma linha noProgram.cs. Além disso, os extension methods comoUser.GetDisplayName()eUser.GetObjectId()facilitam a extração de claims do JWT já validado.
Dicas e Boas Práticas
Sempre use PKCE para aplicações públicas: mesmo que o framework não exija, o PKCE protege contra ataques de interceptação de authorization code. O Azure Entra ID suporta PKCE para todos os fluxos.
Prefira certificados a Client Secrets para produção: Client Secrets expiram e podem ser vazados em logs. Certificados gerenciados pelo Azure Key Vault são mais seguros e com rotação automatizada.
Defina escopos granulares na sua API: em vez de um único escopo genérico, crie escopos como
User.Read,User.Write,Admin.Fullpara aplicar o princípio do menor privilégio.Valide TODOS os campos do JWT na sua API: não confie apenas na assinatura. Valide
iss,aud,exp,nbfe os scopes/roles necessários para cada endpoint.Use Managed Identities quando possível: para serviços rodando no Azure (App Service, Functions, VMs), use Managed Identities em vez de Client Secrets. Isso elimina a necessidade de gerenciar credenciais.
Configure tempos de expiração adequados: Access Tokens devem ter vida curta (padrão: 1 hora no Azure Entra). Use Refresh Tokens para renovação. Nunca estenda o tempo de expiração de forma exagerada.
Implemente logout corretamente: além de limpar tokens localmente, redirecione o usuário para o endpoint de logout do Azure Entra (
/oauth2/v2.0/logout) para encerrar a sessão no provedor de identidade.
⚠️ Atenção: Nunca valide tokens apenas no front-end. A validação real deve ocorrer na API (Resource Server). O front-end pode inspecionar o ID Token para exibir informações do usuário, mas a autorização sempre acontece no backend.
Conclusão
Compreender a diferença entre autenticação e autorização é o fundamento para construir sistemas seguros. O JWT oferece um formato compacto e autocontido para transportar claims de identidade e permissões. O OAuth 2.0 resolve o problema da delegação de acesso sem expor credenciais, enquanto o OpenID Connect adiciona a camada de identidade que permite saber quem é o usuário autenticado.
Na prática, ao usar o Azure Entra ID, a escolha do tipo correto de Client ID é determinante para a segurança da sua aplicação: aplicações SPA usam clientes públicos com PKCE, aplicações server-side usam clientes confidenciais com secrets, e APIs/daemons usam o fluxo Client Credentials para comunicação machine-to-machine.
O mais importante é seguir o princípio de que cada aplicação deve ter apenas as permissões necessárias para executar sua função. Para SPAs que lidam com dados sensíveis, considere adotar o padrão BFF (Backend For Frontend), que move os tokens para o servidor — veja como implementar em BFF Backend For Frontend: Segurança em SPAs. Se você gostou deste conteúdo, deixe um comentário com suas dúvidas ou compartilhe com outros desenvolvedores. Para aprofundar seus conhecimentos em automação de projetos, confira também Makefile: Automatizando tarefas para Python, Hugo e Docker.
Leia Também
- BFF Backend For Frontend: Segurança em SPAs
- Terminal vs Pipeline: diferenças ao executar scripts
- Makefile: Automatizando tarefas para Python, Hugo e Docker
- O Programador Pragmático: lições práticas do livro
Referências
- Microsoft Identity Platform — Visão geral — documentação oficial do Azure Entra ID (antigo Azure AD) e seus fluxos de autenticação.
- RFC 7519 — JSON Web Token (JWT) — especificação oficial do JWT pela IETF.
- RFC 6749 — OAuth 2.0 Authorization Framework — especificação oficial do OAuth 2.0.
- RFC 7636 — Proof Key for Code Exchange (PKCE) — extensão de segurança para OAuth 2.0 usada em clientes públicos.
- OpenID Connect Core 1.0 — especificação oficial do OpenID Connect.
- @azure/msal-angular — MSAL Angular — biblioteca oficial da Microsoft para autenticação em SPAs Angular.
- MSAL Python — Microsoft Authentication Library para Python — biblioteca oficial da Microsoft para autenticação em aplicações Python.
- Microsoft.Identity.Web — Proteção de APIs ASP.NET Core — documentação oficial para proteger APIs com Azure Entra ID no ASP.NET Core.
- Microsoft.Identity.Web — Repositório GitHub — código-fonte e exemplos oficiais do pacote NuGet.
- OAuth 2.0 Security Best Current Practice (IETF) — recomendações de segurança atualizadas para implementações OAuth 2.0.
- Azure Key Vault — Visão geral — serviço de gerenciamento de segredos, chaves e certificados do Azure.
Ao comentar, você concorda com nossa Política de Privacidade, Termos de Uso e Política de Exclusão de Dados.