Provedores de identidade: o que são Azure AD (Entra ID), OAuth e OpenID Connect e por que usar

Todo sistema começa com a mesma tela: e-mail e senha. E quase todo sistema acaba implementando a mesma coisa do zero: cadastro, hash de senha, recuperação por e-mail, bloqueio por tentativas, autenticação em dois fatores, sessão, logout. É código que não diferencia o seu produto e que, se tiver uma falha, abre a porta para todo o resto. Neste artigo, explicamos o que é um provedor de identidade, onde entram nomes como Azure AD (hoje Microsoft Entra ID), OAuth 2.0, OpenID Connect e SAML, e por que delegar o login costuma ser a decisão mais segura e mais barata.

O que é um provedor de identidade

Um provedor de identidade (em inglês, Identity Provider ou IdP) é o serviço responsável por responder a uma pergunta: quem é esta pessoa? Ele guarda as contas, confere a senha ou a passkey, exige o segundo fator, aplica as regras de acesso e, no fim, entrega para a sua aplicação um documento assinado dizendo “este é o usuário X, autenticado agora, com estes dados”.

Você já usa provedores de identidade todos os dias: o botão “Entrar com Google”, o login com a conta Microsoft do trabalho para abrir o Teams, o acesso ao sistema da empresa sem digitar outra senha. Em todos esses casos, a aplicação não vê a sua senha. Ela só recebe a confirmação de quem você é.

Na linguagem técnica, a aplicação que confia no provedor é chamada de Relying Party (no OpenID Connect) ou Service Provider (no SAML). O importante é a divisão de papéis: o provedor cuida da identidade, a aplicação cuida do negócio.

Azure AD, OAuth, OIDC, SAML: o que é cada coisa

Boa parte da confusão vem de misturar produtos com protocolos. Azure AD é um produto. OAuth é um protocolo. Não são alternativas entre si: o Azure AD fala OAuth.

Os produtos (os provedores)

• Microsoft Entra ID (antigo Azure AD): o diretório de identidades da Microsoft, que já vem com todo tenant do Microsoft 365. A Microsoft trocou o nome em 2023, mas o serviço, as APIs e os endereços de login continuam os mesmos. É a escolha natural para sistemas internos de empresas que já usam Microsoft 365.
• Microsoft Entra External ID: a versão para clientes e parceiros (o chamado CIAM), sucessora do Azure AD B2C, que deixou de ser vendido para novos clientes em 2025.
• Google: login com contas Google e Google Workspace, muito usado em apps para o consumidor final.
• Okta e Auth0 (da Okta): plataformas independentes de nuvem, fortes em integrações prontas e em personalização do fluxo de login.
• Amazon Cognito: o provedor da AWS, comum em aplicações que já rodam lá.
• Keycloak: provedor de código aberto que você hospeda na sua própria infraestrutura. Sem custo de licença, mas com o custo de operar, atualizar e proteger.

Os protocolos (a língua que eles falam)

• OAuth 2.0: protocolo de autorização. Ele resolve “este app pode acessar aquele recurso em nome do usuário?”, entregando um access token. É o que permite, por exemplo, um sistema ler a sua agenda do Google sem conhecer a sua senha. Sozinho, o OAuth não diz quem é o usuário.
• OpenID Connect (OIDC): uma camada de autenticação sobre o OAuth 2.0. Acrescenta o ID token, um JWT assinado com a identidade do usuário. Quando um site diz “login com OAuth”, quase sempre está usando OIDC.
• SAML 2.0: padrão mais antigo, baseado em XML, ainda muito presente em sistemas corporativos e no SSO entre empresas. Funciona bem em aplicações web, mas é desajeitado para apps mobile e SPAs.

Protocolo	Responde a	Entrega	Onde aparece
OAuth 2.0	O que este app pode acessar?	Access token	APIs, integrações entre sistemas
OpenID Connect	Quem é o usuário?	ID token (JWT) + access token	Login em sites, SPAs e apps mobile
SAML 2.0	Quem é o usuário?	Asserção XML assinada	SSO corporativo e sistemas legados

Como funciona um login com provedor de identidade

O fluxo recomendado hoje para sites, SPAs e apps é o Authorization Code com PKCE. Em resumo:

1. O usuário clica em “Entrar”. A aplicação o redireciona para o provedor, informando quem ela é (client_id), para onde voltar e o que precisa (scope).
2. O provedor mostra a tela de login, confere senha, passkey ou segundo fator e aplica as políticas da empresa (país, dispositivo, horário).
3. Se tudo estiver certo, o provedor devolve o usuário para a aplicação com um código de uso único.
4. A aplicação troca esse código, direto com o provedor, pelos tokens: o ID token (quem é o usuário) e o access token (para chamar APIs).
5. A aplicação valida a assinatura do ID token, cria a sessão e pronto: o usuário está dentro, e a senha nunca passou pelo seu servidor.

O primeiro redirecionamento, no caso do Entra ID, é parecido com isto:

GET https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/authorize
    ?client_id={id-do-app}
    &response_type=code
    &redirect_uri=https://app.suaempresa.com.br/signin-oidc
    &scope=openid profile email
    &state={valor-aleatorio}
    &code_challenge={hash-do-verificador}
    &code_challenge_method=S256

O state protege contra falsificação de requisição, e o par code_challenge/verificador (o PKCE) garante que só quem iniciou o login consegue trocar o código pelos tokens. O ID token que volta, depois de decodificado, traz algo assim:

{
  "iss": "https://login.microsoftonline.com/{tenant-id}/v2.0",
  "aud": "{id-do-app}",
  "sub": "AAAAAAAAAAAAAAAAAAAAAIkzqFVrSaSaFHy782bbtaQ",
  "name": "Maria Souza",
  "email": "[email protected]",
  "tid": "{tenant-id}",
  "iat": 1794326400,
  "exp": 1794330000
}

Por que usar um provedor de identidade

1. Senha deixa de ser problema seu

Se o seu banco não guarda senhas, um vazamento do banco não vaza senhas. O provedor cuida de hash, proteção contra força bruta, detecção de senhas vazadas e recuperação de conta, coisas que times grandes erram e times pequenos nem chegam a implementar.

2. MFA e passkeys sem escrever uma linha

Segundo a Microsoft, a autenticação multifator bloqueia mais de 99,9% dos ataques de comprometimento de conta. Com um provedor, ligar MFA, aplicativo autenticador, passkeys (FIDO2/WebAuthn) ou login sem senha é configuração, não projeto.

3. Um login para todos os sistemas (SSO)

O colaborador entra uma vez e acessa o ERP, o CRM, o portal interno e as aplicações sob medida. Menos senhas significa menos senhas fracas, menos post-its no monitor e menos chamados de “esqueci a senha”.

4. Desligou o funcionário, desligou o acesso

Este é, na prática, o argumento mais forte para empresas. Com cada sistema mantendo o próprio cadastro, alguém sempre esquece de remover o acesso de quem saiu. Com o Entra ID, desativar a conta corta o acesso a tudo o que está integrado, na hora.

5. Acesso condicional e auditoria

Provedores corporativos permitem regras como “só acessa o financeiro a partir de dispositivo da empresa” ou “login fora do Brasil exige MFA”, além de registrar quem entrou, quando e de onde. Esses registros ajudam a responder a incidentes e a demonstrar controle de acesso em auditorias e na adequação à LGPD.

6. Menos código para manter

Cadastro, recuperação de senha, verificação de e-mail, bloqueio, MFA e sessão viram responsabilidade de um serviço especializado. O seu time escreve o que diferencia o produto.

Na prática: protegendo uma aplicação .NET com o Entra ID

No ASP.NET Core, a biblioteca Microsoft.Identity.Web faz quase todo o trabalho. Depois de registrar a aplicação no portal do Entra ID, o login em uma aplicação web fica assim:

// Program.cs
builder.Services
    .AddAuthentication(OpenIdConnectDefaults.AuthenticationScheme)
    .AddMicrosoftIdentityWebApp(builder.Configuration.GetSection("AzureAd"));

builder.Services.AddAuthorization(o =>
{
    // sem login, nenhuma pagina abre
    o.FallbackPolicy = o.DefaultPolicy;
});

// appsettings.json (o segredo fica no Key Vault ou em variavel de ambiente)
"AzureAd": {
  "Instance": "https://login.microsoftonline.com/",
  "TenantId": "{tenant-id}",
  "ClientId": "{id-do-app}",
  "CallbackPath": "/signin-oidc"
}

Para uma API, o padrão é receber o access token no cabeçalho Authorization: Bearer e validar emissor, público e assinatura a cada requisição:

builder.Services
    .AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddMicrosoftIdentityWebApi(builder.Configuration.GetSection("AzureAd"));

Em Node.js e Next.js, bibliotecas como Auth.js e openid-client fazem o mesmo papel, e como todos os provedores falam OIDC, a troca de Entra ID por Google, Okta ou Keycloak costuma ser só de configuração.

Os erros mais comuns na integração

• Usar o access token como prova de login. O access token é para a API. Quem diz quem é o usuário é o ID token do OIDC.
• Não validar o token. Assinatura, emissor (iss), público (aud) e validade (exp) precisam ser conferidos em toda requisição. As bibliotecas oficiais fazem isso; código caseiro costuma esquecer.
• Aceitar qualquer tenant. Aplicações multi-tenant no Entra ID que usam o endpoint common precisam conferir o tid, ou qualquer conta Microsoft do mundo consegue entrar.
• Fluxo implícito. O implicit flow devolve tokens direto na URL e está desaconselhado pelas boas práticas atuais do OAuth (RFC 9700). Use Authorization Code com PKCE.
• Segredo no front-end ou no app. SPA e app mobile não guardam segredo. Eles são clientes públicos e devem usar PKCE.
• Token no localStorage. Qualquer script injetado na página lê o localStorage. Prefira cookies HttpOnly e Secure no servidor ou o padrão backend for frontend.
• Permissões amplas demais. Peça só os scopes necessários e use papéis (app roles) e grupos do provedor para decidir quem pode o quê.

Qual provedor escolher

Cenário	Escolha mais comum
Sistemas internos de empresa que usa Microsoft 365	Microsoft Entra ID
Sistemas internos de empresa que usa Google Workspace	Google ou um provedor que federe com ele
App ou portal para clientes finais	Entra External ID, Auth0, Cognito ou Firebase Authentication
Muitos sistemas de terceiros e SSO corporativo	Okta ou Entra ID
Exigência de rodar tudo na própria infraestrutura	Keycloak

Alguns cuidados valem para qualquer escolha: confira o modelo de preço (muitos cobram por usuário ativo por mês, o que pesa em apps para consumidor final), onde os dados ficam armazenados e se o provedor fala OIDC e SAML. Ficar nos protocolos padrão é o que evita ficar preso a um fornecedor.

Quando não vale a pena

Quase sempre vale. As exceções são raras: sistemas sem acesso à internet, exigências regulatórias muito específicas sobre onde a identidade é processada ou casos em que o custo por usuário inviabiliza o modelo de negócio. Mesmo aí, a resposta costuma ser um provedor auto-hospedado como o Keycloak, e não voltar a guardar senhas na tabela usuarios.

Checklist

• A aplicação não armazena senhas, só o identificador do usuário (sub ou oid) vindo do provedor
• Login com OpenID Connect, fluxo Authorization Code com PKCE
• Tokens validados em toda requisição (assinatura, iss, aud, exp)
• MFA obrigatório, de preferência com passkeys ou aplicativo autenticador
• Permissões por papéis e grupos do provedor, não por listas no código
• Segredos e certificados do app em cofre (Key Vault ou equivalente), com data de renovação
• Desligamento de colaboradores feito em um único lugar
• Logs de login acompanhados e alertas para acessos suspeitos

Fontes

• Microsoft Learn: novo nome do Azure AD (Microsoft Entra ID)
• Microsoft Learn: fluxo Authorization Code na plataforma de identidade
• IETF RFC 6749: OAuth 2.0, RFC 7636: PKCE e RFC 9700: boas práticas de segurança do OAuth 2.0
• OpenID Foundation: OpenID Connect Core 1.0
• Microsoft Security Blog: MFA e os 99,9% dos ataques a contas

Precisa de ajuda?

Quer tirar o login de dentro do seu sistema, integrar as aplicações da empresa ao Entra ID ou ao Google ou colocar SSO e MFA em um portal de clientes? Fale com a gente: fazemos a integração com o provedor certo para o seu caso, sem parar quem já usa o sistema.