Nosso blog da aula anterior tem uma falha gritante: qualquer pessoa pode escrever posts, porque não há controle de acesso. Num blog de verdade, só o autor autenticado deveria poder publicar. Resolver isso nos leva a um dos temas mais importantes — e mais sensíveis — do desenvolvimento web: a segurança de acesso. Esta aula distingue os dois conceitos que a compõem, mostra como adicioná-los ao blog com o sistema pronto de contas do ASP.NET Core, e — porque segurança é uma área onde erros custam caro — enfatiza um princípio que você deve gravar: nunca implemente a segurança de autenticação por conta própria; use um sistema testado. Senhas mal guardadas e logins malfeitos são a origem de incontáveis vazamentos de dados, e a boa notícia é que o C# já resolve isso de forma robusta, para que você não precise (nem deva) reinventá-la.
Os dois conceitos: autenticação e autorização
Muita gente confunde os dois, mas a distinção é simples e fundamental. Autenticação responde à pergunta "quem é você?" — é o processo de verificar a identidade de alguém, tipicamente por login e senha. Autorização responde a "o que você pode fazer?" — é o processo de decidir se um usuário já identificado tem permissão para uma determinada ação. A ordem importa: primeiro você autentica (descobre quem é), depois autoriza (verifica se pode). A analogia clássica: a autenticação é mostrar seu documento na portaria de um prédio (provar quem você é); a autorização é o crachá que determina a quais andares você tem acesso (o que você pode fazer). No nosso blog, a autenticação será o login do autor; a autorização será a regra "só usuários logados podem criar posts".
O princípio inegociável: não reinvente a segurança
Antes de qualquer código, o aviso mais importante desta aula. A segurança de autenticação é notoriamente difícil de acertar e desastrosa quando errada. Guardar senhas exige técnicas criptográficas corretas — senhas jamais devem ser guardadas como texto puro no banco, e sim transformadas por processos matemáticos especializados que impedem sua recuperação. Gerenciar sessões de login exige cuidados contra sequestro de identidade. Há dezenas de detalhes onde um erro sutil abre uma brecha grave. Por isso, a regra profissional é absoluta: você não implementa isso do zero. Assim como você não escreveria sua própria criptografia, não escreve seu próprio sistema de senhas. Você usa uma solução testada, auditada e mantida por especialistas — no C#, o sistema de identidade do ASP.NET Core, que cuida da guarda segura de senhas, do login, do bloqueio após tentativas falhas, e de todo o resto, corretamente.
Este não é um conselho de preguiça; é de responsabilidade. Reinventar a segurança é como fazer sua própria instalação elétrica sem saber: pode até "funcionar", até o dia em que pega fogo. Um sistema com autenticação mal-feita pode expor as senhas de todos os seus usuários num único vazamento — um dano enorme e irreversível. Use o que os especialistas construíram; em segurança, a humildade é uma virtude técnica.
Passo 1: adicionar o sistema de identidade
O sistema de identidade do ASP.NET Core integra-se ao EF Core que você já usa: ele guarda os usuários e suas senhas (transformadas de forma segura) no seu próprio banco de dados. Adicionamos os pacotes necessários e configuramos. Primeiro, o contexto do blog passa a herdar do contexto de identidade, que já traz as tabelas de usuários prontas:
dotnet add package Microsoft.AspNetCore.Identity.EntityFrameworkCore
dotnet add package Microsoft.AspNetCore.Identity.UI
using Microsoft.AspNetCore.Identity.EntityFrameworkCore;
// Herda de IdentityDbContext: ganha as tabelas de usuários, senhas seguras, etc.
class BlogContext : IdentityDbContext
{
public BlogContext(DbContextOptions<BlogContext> opcoes) : base(opcoes) { }
public DbSet<Post> Posts => Set<Post>();
}
Ao herdar de IdentityDbContext, seu banco ganha automaticamente toda a estrutura de contas (tabelas de usuários, senhas guardadas com segurança), sem que você a modele. No Program.cs, registramos o sistema de identidade e o ativamos:
builder.Services.AddDbContext<BlogContext>(o =>
o.UseNpgsql("Host=localhost;Database=blog_db;Username=curso;Password=senha123"));
// Registra o sistema de identidade, usando o BlogContext para guardar os usuários:
builder.Services
.AddDefaultIdentity<IdentityUser>(opcoes => opcoes.SignIn.RequireConfirmedAccount = false)
.AddEntityFrameworkStores<BlogContext>();
builder.Services.AddRazorPages();
var app = builder.Build();
app.UseAuthentication(); // ATIVA a autenticação (quem é você?)
app.UseAuthorization(); // ATIVA a autorização (o que você pode?)
Duas linhas cruciais no fim: UseAuthentication() liga o mecanismo que identifica o usuário a cada acesso, e UseAuthorization() liga o que verifica permissões. A ordem importa — autenticação antes de autorização, como discutimos. Depois, geramos uma migração e a aplicamos (dotnet ef migrations add AdicionaIdentity e database update), e o sistema de identidade traz junto páginas prontas de registro e login, poupando você de criar formulários de senha à mão — justamente a parte delicada que não devemos escrever sozinhos.
Passo 2: proteger uma página (autorização)
Com o sistema de identidade ativo, proteger a página de criação de posts é surpreendentemente simples. Basta o atributo [Authorize] no código da página, e o ASP.NET Core passa a exigir que o usuário esteja autenticado para acessá-la:
using Microsoft.AspNetCore.Authorization;
[Authorize] // só usuários AUTENTICADOS acessam esta página
public class CriarModel : PageModel
{
// ... o resto do código da página de criação, igual à aula anterior ...
}
Só isso. Com [Authorize], se um visitante não logado tentar acessar a página de criação, o ASP.NET Core automaticamente o redireciona para a página de login — ele não consegue nem ver o formulário sem se autenticar. É a autorização em ação: o sistema já sabe quem está logado (autenticação) e usa essa informação para decidir o acesso (autorização). Você declarou a regra ("esta página exige login") e o sistema a aplica. A leitura do blog continua livre para todos; só a criação de posts fica protegida — exatamente o comportamento que um blog espera.
A perspectiva de segurança
Encerro reforçando o quadro maior. Você adicionou autenticação e autorização robustas ao blog escrevendo pouquíssimo código de segurança — porque delegou o difícil (a guarda segura de senhas, o login, as sessões) a um sistema testado por milhares de aplicações. Isso é exatamente como deve ser. Sua responsabilidade como programador não é inventar segurança, mas usar corretamente as ferramentas de segurança comprovadas: registrar o sistema, proteger as páginas certas com [Authorize], e verificar permissões onde importam. Erros de segurança quase nunca vêm de quem usou uma biblioteca consagrada; vêm de quem tentou fazer sozinho "para aprender" ou "porque parecia simples". Você aprendeu a lição mais importante sobre segurança que existe: reconhecer o que não deve escrever você mesmo, e apoiar-se em quem já resolveu o problema corretamente.
A distinção entre autenticação e autorização ficou clara: uma verifica quem é, a outra decide o que essa pessoa pode fazer. Com o sistema de identidade do ASP.NET Core, cadastro, login e proteção de páginas entraram na aplicação sem exigir implementação própria.
E o princípio que abriu a aula é o que mais importa carregar adiante: segurança não se reinventa. Guardar senhas corretamente, gerenciar sessões sem abrir brechas e bloquear tentativas repetidas envolve detalhes criptográficos fáceis de errar de formas que só aparecem quando já foram exploradas. Usar uma solução auditada e mantida por especialistas não é preguiça — é responsabilidade profissional.
Fontes e leituras recomendadas
- Introdução ao ASP.NET Core Identity — a documentação oficial do sistema de contas; a base desta aula.
- Autenticação versus autorização — a distinção conceitual e como o ASP.NET Core trata cada uma.
- O atributo Authorize — como proteger páginas e rotas por autorização.
- Guarda segura de senhas — por que e como o sistema guarda senhas com segurança, nunca como texto puro.
- Boas práticas de segurança no ASP.NET Core — o panorama de segurança da plataforma, para aprofundar.
Exercícios
Exercício 1
Adicione o sistema de identidade ao blog: instale os pacotes, faça o BlogContext herdar de IdentityDbContext, registre a identidade no Program.cs e aplique a migração. Confirme que as páginas de registro e login (que vêm prontas) estão acessíveis.
Ver resposta
✓ Resposta: Após instalar os pacotes do sistema de identidade, fazer o BlogContext herdar de IdentityDbContext, registrar com AddDefaultIdentity<IdentityUser>().AddEntityFrameworkStores<BlogContext>() e adicionar UseAuthentication()/UseAuthorization(), gera-se e aplica-se a migração. As tabelas de usuários são criadas no banco, e as páginas prontas de registro e login ficam acessíveis, permitindo criar contas sem escrever formulários de senha.
Exercício 2
Proteja a página de criação de posts com [Authorize]. Teste acessando a página de criação sem estar logado e confirme que você é redirecionado ao login; depois registre uma conta, faça login e confirme que agora consegue acessá-la.
Ver resposta
✓ Resposta: Com [Authorize] na página de criação, acessá-la deslogado redireciona automaticamente para a página de login. Após registrar uma conta e fazer login, o mesmo acesso passa a exibir o formulário normalmente. Isso confirma a autorização funcionando: o acesso à página depende de o usuário estar autenticado.
Exercício 3
Explique, com suas palavras e um exemplo do blog, a diferença entre autenticação e autorização. Em que momento cada uma acontece quando um usuário logado cria um post?
Ver resposta
✓ Resposta: Autenticação é verificar quem é o usuário — acontece no login, quando ele prova sua identidade com e-mail e senha, e a cada acesso seguinte o sistema reconhece quem está logado. Autorização é decidir o que ele pode fazer — acontece quando ele tenta acessar a página de criação: o [Authorize] verifica se há um usuário autenticado e, em caso afirmativo, permite o acesso. Ao criar um post, primeiro o sistema já sabe quem ele é (autenticação, resolvida no login), e então autoriza a ação de acessar a página protegida e publicar (autorização). Primeiro identifica, depois permite.
Exercício 4
Explique, com suas palavras, por que a leitura dos posts do blog continua livre para todos, enquanto a criação fica protegida. Onde, no código, essa distinção é estabelecida?
Ver resposta
✓ Resposta: A leitura continua livre porque a página de listagem e a de visualização de post não têm o atributo [Authorize] — não há regra exigindo login para acessá-las, então qualquer visitante pode lê-las. A criação fica protegida porque a página de criação tem o [Authorize], que exige um usuário autenticado. A distinção é estabelecida no código pela presença ou ausência do atributo [Authorize] em cada página: onde ele está (a criação), o acesso exige login; onde ele não está (a leitura), o acesso é livre. Assim, protege-se seletivamente apenas o que precisa de proteção.
Exercício 5
Sem código: explique por que a aula insiste que você "nunca implemente a segurança de autenticação por conta própria". Que risco específico surge ao tentar guardar senhas manualmente, e por que usar o sistema de identidade o evita?
Ver resposta
✓ Resposta: A aula insiste nisso porque acertar a segurança de autenticação exige conhecimentos criptográficos e de gerenciamento de sessão que são fáceis de errar de formas invisíveis até serem exploradas. O risco específico ao guardar senhas manualmente é armazená-las de forma insegura — como texto puro ou com técnicas fracas —, o que significa que, num único vazamento do banco de dados, todas as senhas dos usuários ficariam expostas, um dano enorme e irreversível. Usar o sistema de identidade evita isso porque ele já guarda as senhas com técnicas criptográficas corretas (transformando-as por processos que impedem sua recuperação), além de tratar login, sessões e bloqueios de forma segura e auditada. Delegar essa parte a um sistema testado transfere a responsabilidade mais perigosa para código comprovado, deixando a você apenas a tarefa segura de configurá-lo e aplicá-lo corretamente.