Aula 9 • Projeto 9 • Sistemas de Informação

Segurança e autorização em API

Segurança como requisito não funcional: de storytelling de risco a autenticação moderna, MFA, JWT e decisão arquitetural para o projeto.

Storytelling SWEBOK + NFR MFA + JWT Keycloak/Auth0

Prof. Afonso Brandão • 2 horas • Semana 06

Storytelling: o dashboard que vazou sem “hack sofisticado”

Segurança não começa com criptografia. Começa com contexto de negócio.

Cenário

Uma empresa cria um dashboard gerencial com dados de desempenho, salários variáveis, turnover e projeção de metas. A API funciona, o deploy está no ar e o time comemora a entrega.

O incidente

Um colaborador recebe um link falso, entrega a senha em uma página clonada e um atacante entra com credenciais válidas.

O dano real

O problema não é só “logar”. O invasor exporta indicadores internos, acessa relatórios de RH e compromete decisões estratégicas.

A lição

Sem autenticação forte, autorização adequada, logs e trilha de auditoria, o sistema estava funcional, mas não estava pronto.

O que é o SWEBOK e onde segurança aparece

SWEBOK = Guide to the Software Engineering Body of Knowledge.

O SWEBOK organiza o conhecimento essencial de engenharia de software.

Como ler isso para segurança

Não trate segurança como um tema isolado ou “do time de infraestrutura”.
No SWEBOK, segurança atravessa requisitos, design, construção, testes, qualidade e manutenção.
Ela é detalhada com mais força quando falamos de qualidade do software e de requisitos de qualidade.

Leitura prática para a aula

Software Requirements: define requisitos de segurança e restrições.
Software Design: transforma risco em arquitetura, controles e separação de responsabilidades.
Software Testing / Quality: valida se o controle realmente funciona.

Ler SWEBOK

Segurança como requisito não funcional

Ela não descreve “o que o sistema faz”, e sim “como o sistema deve se comportar sob risco”.

Pergunta	Exemplo funcional	Exemplo não funcional de segurança
O que o sistema entrega?	“Gerar relatório de indicadores do RH.”	“Somente gestores autorizados podem acessar relatórios agregados do RH.”
Como a API responde?	“Disponibilizar endpoint de exportação.”	“Exigir token válido, MFA no login e registrar trilha de auditoria.”
Que evidência esperamos?	“O endpoint retorna um arquivo CSV.”	“Tentativas inválidas geram `401`, acessos sem permissão geram `403` e eventos ficam rastreáveis.”

Autenticação x autorização

Confundir esses conceitos gera bugs de negócio e falhas graves de acesso.

Autenticação

“Quem é você?”

Valida identidade.
Ex.: senha, biometria, TOTP, login social, certificado.
Se falhar, o usuário nem entra no sistema.
Na API, costuma resultar em 401 Unauthorized.

Autorização

“O que você pode fazer?”

Valida permissões e escopo de ação.
Ex.: role admin, claim department=finance, policy CanExportReports.
O usuário pode estar autenticado e ainda assim ser barrado.
Na API, costuma resultar em 403 Forbidden.

Resumo para projeto

Login sem política de acesso é perigoso. Política sem identidade forte também. Você precisa das duas camadas.

Os três estágios da segurança

Uma defesa madura não só bloqueia. Ela também enxerga e explica.

1

Conter

Impedir o acesso indevido.
MFA, rate limit, senha forte, expiração de token, política por papel.
É a camada de barreira.

2

Observar comportamento

Perceber anomalias e abuso.
Logins de local estranho, excesso de tentativas, exportações fora do padrão.
É a camada de monitoramento.

3

Rastrear

Reconstruir o incidente com evidências.
Quem acessou, quando, com qual token, em qual endpoint, com qual resultado.
É a camada de auditoria e resposta.

Por que a senha está ficando obsoleta

Não porque criptografia falhou, mas porque o elo fraco continua sendo humano.

O problema das senhas

Reuso entre sistemas.
Phishing e páginas falsas.
Vazamentos em terceiros.
Senhas previsíveis ou compartilhadas.
Engenharia social contorna a “força” da senha.

O que vem no lugar

MFA baseado em posse: app autenticador, push, token físico.
Biometria e passkeys.
SSO com provedores corporativos.
Credenciais curtas de vida curta: tokens com expiração.

Ponto-chave

A senha sozinha prova pouco. O invasor pode roubá-la sem “quebrá-la”. Por isso MFA e login resistente a phishing reduzem o impacto da engenharia social.

MFA: o que é e por que funciona

Misturar fatores reduz o risco de um único vazamento comprometer tudo.

Algo que eu sei

Senha, PIN, resposta secreta.

Algo que eu tenho

Celular com Google Authenticator, token físico, app autenticador.

Algo que eu sou

Biometria: digital, face, voiceprint.

Algo que eu faço / onde estou

Padrão de comportamento, dispositivo confiável, contexto geográfico.

Decisão pragmática

Para um projeto acadêmico com API e dashboard, o melhor custo-benefício costuma ser: senha + TOTP via app autenticador + expiração curta de token + trilha de auditoria.

O que é TOTP

Time-based One-Time Password: uma senha temporária gerada a partir de tempo e segredo compartilhado.

Definição simples

TOTP é um código numérico de uso único que muda periodicamente, normalmente a cada 30 segundos. O aplicativo autenticador e o servidor conseguem gerar o mesmo código porque compartilham um segredo cadastrado previamente.

Por que isso ajuda

Mesmo que a senha vaze, o atacante ainda precisa do segundo fator.
O código expira rápido.
Não depende de SMS, que costuma ser mais frágil.

Leitura correta

TOTP não substitui a senha por completo. Ele adiciona uma prova extra de posse do dispositivo do usuário. É por isso que o Google Authenticator é um mecanismo de MFA, não um login isolado.

Como funciona TOTP com Google Authenticator no .NET

O app e o servidor compartilham um segredo e geram códigos temporários sincronizados.

1

Provisionamento

O sistema gera um segredo por usuário e exibe QR Code no formato otpauth://.

2

Cadastro no app

O usuário lê o QR Code no Google Authenticator e passa a gerar códigos de 30 em 30 segundos.

3

Validação

No login, servidor valida e só então emite a sessão ou o JWT.

// Exemplo conceitual com Otp.NET
var secret = KeyGeneration.GenerateRandomKey(20);
var base32Secret = Base32Encoding.ToString(secret);

var otpUri =
  $"otpauth://totp/Projeto9:{email}?secret={base32Secret}&issuer=Projeto9";

var totp = new Totp(Base32Encoding.ToBytes(base32Secret));
var isValid = totp.VerifyTotp(codigoDigitado, out _, VerificationWindow.RfcSpecifiedNetworkDelay);

if (!isValid)
{
    return Unauthorized("Codigo MFA invalido.");
}

Em produção, o segredo precisa ficar protegido em banco e nunca exposto novamente após o onboarding.

Fluxo recomendado no backend .NET

Primeiro valida identidade. Depois segundo fator. Só então entrega credencial de acesso.

Fluxograma

Início: usuário envia login e senha

↓

Backend valida credenciais primárias

↓

MFA está habilitado para esse usuário?

Não

↓

Emitir JWT ou cookie de sessão

Sim

↓

Retornar desafio de segundo fator

↓

Usuário envia código TOTP

↓

Código TOTP é válido?

Não

↓

Negar acesso e registrar falha

Sim

↓

Emitir JWT ou cookie de sessão

Regras mínimas

Segredo MFA por usuário.
Códigos de recuperação.
Bloqueio após muitas tentativas.
Logs de ativação, falha e uso do MFA.
Revogação de sessões suspeitas.

JWT: como funciona

JWT não é “segurança mágica”. É um formato de token assinado com regras claras de uso.

Estrutura

header.payload.signature

Header: algoritmo e tipo do token.
Payload: claims como usuário, papel, escopo, expiração.
Signature: prova de integridade e emissor confiável.

Vantagens

Bom para APIs stateless.
Transporta claims de autorização.
Integra bem com gateway e SSO.

Cuidados

Não guardar dado sensível no payload.
Expiração curta.
Validar issuer, audience, assinatura e clock skew.
Separar access token de refresh token.

Exemplo de JWT e autorização por claims

O token carrega identidade e contexto. A API decide o acesso com base nisso.

{
  "sub": "user-123",
  "email": "gestor@empresa.com",
  "role": "manager",
  "department": "rh",
  "scope": "reports:read reports:export",
  "iss": "https://auth.projeto9.local",
  "aud": "projeto9-api",
  "exp": 1772804400
}

Exemplo de política

Permitir exportação somente para usuários com scope=reports:export e department=rh.

Erro comum

Usar apenas role genérica e esquecer contexto de domínio, como área, filial, sensibilidade do relatório ou tenant.

Keycloak, Auth0 e o valor de um provedor de identidade

Nem todo time precisa implementar autenticação do zero dentro da API.

Keycloak

Open source.
Centraliza login, emissão de tokens, usuários, realms, roles e integração OIDC/OAuth2.
Bom para aprender identidade e ter controle maior da infraestrutura.
Exige operação, configuração e manutenção.

Auth0

Solução gerenciada e paga.
Entrega login, MFA, social login, regras e observabilidade com menor esforço operacional.
Acelera projeto quando o foco não é operar IAM.
Em troca, há custo e dependência de fornecedor.

Leitura correta

Auth0 não é “implementação paga do Keycloak” no sentido técnico estrito. Mas, para fins didáticos, ambos cumprem papel semelhante: externalizar autenticação, emissão de token e parte da governança de acesso.

Duas rotas viáveis para o Projeto 9

Escolham uma abordagem simples, defensável e implementável no tempo do módulo.

Opção 1: Google Authenticator via Firebase

Usar Firebase Authentication como camada de identidade.
Ativar MFA/TOTP no provedor e consumir tokens na aplicação.
Prós: onboarding rápido, menor esforço backend.
Contras: menos controle fino sobre a infraestrutura de identidade.

Opção 2: Auth0

Delegar autenticação, MFA e emissão de JWT ao Auth0.
API valida tokens e aplica autorização por claims/policies.
Prós: arquitetura profissional e limpa para API.
Contras: curva de configuração e custo fora do plano gratuito.

Checklist de segurança mínima para a aplicação

O que deve existir ao final da sprint para a solução ser defensável.

Identidade

Login centralizado.
MFA ativo para perfis críticos.
Expiração e renovação controlada.

Acesso

Policies por papel e claims.
Endpoints sensíveis protegidos.
Distinção correta entre 401 e 403.

Rastro

Logs de login e falha.
Registro de exportações e acessos críticos.
Auditoria mínima para incidentes.

Atividade de pesquisa e decisão do grupo

Vocês vão pesquisar, argumentar e decidir qual abordagem de autenticação entra no projeto.

Entrega

Pesquisar as duas abordagens sugeridas pela aula.
Escolher uma para a aplicação do grupo.
Justificar a escolha em termos de segurança, esforço técnico e aderência ao escopo.
Desenhar o fluxo de login, MFA, emissão de token e autorização da API.

Sugestão A

Google Authenticator via Firebase

Investigar como o provedor cuida da identidade e como a API consome o token com confiança.

Sugestão B

Auth0

Investigar como delegar autenticação, MFA, roles/claims e validação de JWT no backend .NET.

Pergunta final

Se alguém roubar apenas a senha de um usuário hoje, o que exatamente ainda impediria esse atacante de exportar os relatórios sensíveis do seu sistema?