Primeiro, escolha o fluxo pelo tipo de aplicação

Uma aplicação web tradicional pode usar cookies de sessão protegidos pelo servidor. Uma SPA, aplicação mobile ou integração com API costuma usar um provedor de identidade e fluxos OAuth 2.0 apropriados ao cliente. OpenID Connect (OIDC) acrescenta uma camada de identidade sobre OAuth: OAuth trata de autorização delegada; OIDC permite autenticar o usuário e obter informações de identidade.

Não implemente um servidor de identidade próprio apenas para emitir JWTs. Use um provedor confiável, configure clientes e redirecionamentos corretamente e aplique o fluxo recomendado para cada tipo de cliente. Aplicações públicas não conseguem proteger um segredo estático embutido no navegador ou no aplicativo.

JWT é um formato, não uma decisão de segurança

Um access token pode ser um JWT assinado, mas qualquer pessoa que o receba normalmente pode ler seu payload. A assinatura ajuda a verificar integridade e emissor; não criptografa o conteúdo. A API deve validar assinatura, emissor, audiência, validade temporal e demais parâmetros esperados. Decodificar o token e confiar nas claims não equivale a validá-lo.

Tokens devem ter escopo e duração compatíveis com o risco. Não coloque senhas, segredos ou dados pessoais desnecessários no payload. Planeje rotação de chaves, revogação e o impacto de tokens já emitidos.

Configuração de autenticação bearer em ASP.NET Core

Para uma API que aceita tokens de um provedor OIDC, a configuração deve apontar para autoridade e audiência esperadas. As opções concretas dependem do provedor:

builder.Services
    .AddAuthentication("Bearer")
    .AddJwtBearer("Bearer", options =>
    {
        options.Authority = builder.Configuration["Identity:Authority"];
        options.Audience = builder.Configuration["Identity:Audience"];
        options.RequireHttpsMetadata = true;
    });

builder.Services.AddAuthorization(options =>
{
    options.AddPolicy("Pedidos:Leitura", policy =>
        policy.RequireAuthenticatedUser()
              .RequireClaim("scope", "pedidos.read"));
});

app.UseAuthentication();
app.UseAuthorization();

A configuração é ilustrativa: valide os nomes de claims e scopes emitidos pelo seu provedor. Mantenha HTTPS, segredos fora do repositório, e garanta a ordem correta do middleware antes dos endpoints protegidos.

Claims não substituem autorização de domínio

Uma claim pode indicar identidade, tenant, papel ou escopo. A presença de uma claim ampla como “admin” não deve ser assumida como autorização para todo recurso. Políticas ASP.NET Core podem verificar requisitos transversais; a aplicação ainda precisa verificar regras como se aquela pessoa pode alterar aquele pedido específico.

Defina políticas pelo significado da permissão e proteja também operações internas e consumidores de mensagens. Esconder um botão na interface não autoriza uma operação no servidor.

Armazenamento de tokens e erros comuns

Evite guardar tokens de longa duração em armazenamento acessível a scripts no navegador. Cookies exigem proteção contra CSRF conforme o fluxo; tokens bearer em clientes públicos precisam de armazenamento e renovação cuidadosamente projetados. Não registre tokens em logs nem aceite tokens destinados a outra API.

Respostas 401 indicam que a chamada não foi autenticada; 403 indica que foi reconhecida, mas não autorizada. Mantenha respostas sem detalhes sensíveis e registre contexto suficiente para investigar recusas.

Leituras relacionadas