Lab 12 — Autenticação e sessão que não guardam o que não devem

# Rode com desired_count=1, faça login, guarde o cookie. Depois suba para 2.
for i in $(seq 1 100); do
  curl -s -o /dev/null -w "%{http_code}\n" -b cookie.txt "$URL/api/pedidos"
done | sort | uniq -c
# Com 1 task: 100 respostas "200".
# Com 2 tasks, MESMO cookie, sem sessão pegajosa: cerca de 50 respostas "200" e
# 50 "401" — a moeda decide se a requisição caiu na task que conhece o cookie.

// Claims decodificadas de um token de ACESSO do Cognito (exemplo
// ilustrativo, sem segredo nenhum: token de acesso nao carrega senha).
// Repare na AUSENCIA de "aud" e na PRESENCA de "client_id".
{
  "sub": "3f2a1c4e-58b1-4a11-9c2e-1a2b3c4d5e6f",
  "iss": "https://cognito-idp.us-east-1.amazonaws.com/us-east-1_ExemploXX",
  "client_id": "1a2b3c4d5e6f7g8h9i0j",
  "token_use": "access",
  "scope": "https://api.ffv-lab.exemplo/pedidos.leitura https://api.ffv-lab.exemplo/pedidos.escrita",
  "auth_time": 1754575200,
  "exp": 1754576100,
  "iat": 1754575200,
  "jti": "8b7e1a2c-91a0-4f7e-8b1a-2c3d4e5f6a7b",
  "origin_jti": "4d3f9a1b-6c5d-4e3f-9a1b-6c5d4e3f9a1b",
  "username": "ana@lojadoze.exemplo"
}

// O de IDENTIDADE do MESMO login. Repare: tem "aud", NAO tem "client_id",
// e carrega atributo de perfil — e por isso que ele nao serve para
// autorizar chamada de API.
{
  "sub": "3f2a1c4e-58b1-4a11-9c2e-1a2b3c4d5e6f",
  "iss": "https://cognito-idp.us-east-1.amazonaws.com/us-east-1_ExemploXX",
  "aud": "1a2b3c4d5e6f7g8h9i0j",
  "token_use": "id",
  "auth_time": 1754575200,
  "exp": 1754576100,
  "iat": 1754575200,
  "email": "ana@lojadoze.exemplo",
  "email_verified": true,
  "custom:loja_id": "loja-12"
}

# cognito.tf — o pool de usuarios, e o cliente que nao pode guardar segredo

resource "aws_cognito_user_pool" "usuarios" {
  name = "${var.projeto}-usuarios"

  # E-mail e a identidade que a loja usa para logar; nao existe nome de
  # usuario separado que ninguem lembra.
  username_attributes      = ["email"]
  auto_verified_attributes = ["email"]

  password_policy {
    minimum_length    = 12
    require_lowercase = true
    require_uppercase = true
    require_numbers   = true
    require_symbols   = true
  }

  # MFA opcional aqui. Autenticacao adaptativa por risco fica fora do escopo
  # deste modulo — misturar os dois assuntos dilui o nucleo, que e tirar o
  # estado do conteiner.
  mfa_configuration = "OPTIONAL"
  software_token_mfa_configuration {
    enabled = true
  }

  account_recovery_setting {
    recovery_mechanism {
      name     = "verified_email"
      priority = 1
    }
  }

  # Sem isto, um "terraform destroy" apaga a base de usuarios sem aviso.
  # E o unico recurso deste modulo em que isso importa de verdade.
  deletion_protection = "ACTIVE"

  tags = local.tags
}

# Dominio do Hosted UI: e por onde o fluxo de codigo de autorizacao com
# PKCE acontece. O prefixo tem de ser unico GLOBALMENTE entre contas AWS.
resource "aws_cognito_user_pool_domain" "login" {
  domain       = "${var.projeto}-${data.aws_caller_identity.atual.account_id}"
  user_pool_id = aws_cognito_user_pool.usuarios.id
}

# Escopos proprios, alem dos padrao (openid/email). Sao o que autoriza por
# ACAO, nao so por identidade — a diferenca que a secao de autorizacao usa.
resource "aws_cognito_resource_server" "api" {
  identifier   = "https://api.${var.projeto}.exemplo"
  name         = "API de pedidos"
  user_pool_id = aws_cognito_user_pool.usuarios.id

  scope {
    scope_name        = "pedidos.leitura"
    scope_description = "ler pedidos da loja autenticada"
  }
  scope {
    scope_name        = "pedidos.escrita"
    scope_description = "criar e alterar pedidos"
  }
}

resource "aws_cognito_user_pool_client" "spa" {
  name         = "${var.projeto}-spa"
  user_pool_id = aws_cognito_user_pool.usuarios.id

  # SEM secret. Um navegador nao tem onde guardar um segredo de verdade —
  # ele acaba no bundle JavaScript, legivel por qualquer um. PKCE
  # substitui o segredo por um par verificador/desafio gerado a cada login.
  generate_secret = false

  allowed_oauth_flows_user_pool_client = true
  allowed_oauth_flows                  = ["code"]
  allowed_oauth_scopes = [
    "openid", "email",
    "${aws_cognito_resource_server.api.identifier}/pedidos.leitura",
    "${aws_cognito_resource_server.api.identifier}/pedidos.escrita",
  ]
  supported_identity_providers = ["COGNITO"]

  callback_urls = ["https://loja.${var.projeto}.exemplo/autenticado"]
  logout_urls   = ["https://loja.${var.projeto}.exemplo/"]

  # Nao revela SE o e-mail existe — reduz enumeracao de conta, ao custo de
  # uma mensagem de erro um pouco menos especifica no login.
  prevent_user_existence_errors = "ENABLED"

  # As tres validades, explicitas. O valor do token de acesso e o UNICO
  # termo que voce controla na formula de atraso de revogacao — por isso
  # ele fica curto aqui, abaixo do padrao do console.
  access_token_validity  = 15
  id_token_validity      = 15
  refresh_token_validity = 30
  token_validity_units {
    access_token  = "minutes"
    id_token      = "minutes"
    refresh_token = "days"
  }

  # Explicito, embora ja seja o padrao em app client novo: e o que faz
  # RevokeToken e GlobalSignOut terem efeito sobre o token de atualizacao.
  enable_token_revocation = true
}

output "autoridade_do_pool" {
  value       = "https://cognito-idp.${var.regiao}.amazonaws.com/${aws_cognito_user_pool.usuarios.id}"
  description = "Authority que o middleware JwtBearer usa para achar o JWKS via OIDC discovery"
}

# alb.tf — grupo de destino sem afinidade, e listener que so encaminha

resource "aws_lb_target_group" "api" {
  name        = "${var.projeto}-api"
  port        = 8080
  protocol    = "HTTP"
  vpc_id      = aws_vpc.principal.id
  target_type = "ip" # awsvpc: o alvo e o IP da task, nao a instancia

  health_check {
    path                = "/health/ready"
    interval            = 15
    healthy_threshold   = 2
    unhealthy_threshold = 2
    matcher             = "200"
  }

  # O criterio de aceite deste laboratorio, em uma linha de Terraform: se
  # qualquer task serve qualquer cliente, o estado saiu do conteiner.
  # Afinidade ligada esconderia um bug de sessao em memoria atras de
  # "funciona na pratica" — e foi exatamente o que sustentou o desenho
  # minimo por tanto tempo.
  stickiness {
    enabled = false
    type    = "lb_cookie"
  }
}

resource "aws_lb_listener_rule" "api" {
  listener_arn = aws_lb_listener.https.arn
  priority     = 10

  action {
    # Decisao registrada na secao de decisoes: o ALB SO encaminha. Ele nao
    # usa a acao nativa "authenticate-cognito" porque ela nao entrega o
    # token de acesso ao alvo em forma utilizavel pela API, cria sessao
    # por cookie e exige listener HTTPS dedicado — um desenho diferente
    # do que este modulo ensina, e coberto na secao de alternativas.
    type             = "forward"
    target_group_arn = aws_lb_target_group.api.arn
  }

  condition {
    path_pattern {
      values = ["/api/*"]
    }
  }
}

// Program.cs — a task nao guarda quem entrou; ela CONFERE quem entrou

using System.Security.Claims;
using Microsoft.AspNetCore.Authentication.JwtBearer;
using Microsoft.IdentityModel.Tokens;

var builder = WebApplication.CreateBuilder(args);

var authority = builder.Configuration["Cognito:Authority"]!;   // https://cognito-idp.{regiao}.amazonaws.com/{poolId}
var clienteEsperado = builder.Configuration["Cognito:ClientId"]!;

builder.Services
    .AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddJwtBearer(o =>
    {
        // A Authority basta para a biblioteca achar
        // {authority}/.well-known/openid-configuration, de la o jwks_uri, e
        // fazer o cache de chave publica por `kid` sozinha, via um
        // ConfigurationManager interno com atualizacao automatica. Nao ha
        // codigo de cache neste arquivo porque ele ja vem pronto na
        // biblioteca — e e esse mecanismo que torna a validacao local.
        o.Authority = authority;

        o.TokenValidationParameters = new TokenValidationParameters
        {
            ValidateIssuer = true,
            ValidIssuer    = authority,

            // O ACHADO deste laboratorio: o token de ACESSO do Cognito nao
            // tem a claim `aud` — ele tem `client_id`. Deixar isto em true
            // (o padrao da biblioteca) derruba toda chamada com erro de
            // audiencia, mesmo com um token perfeitamente valido. A
            // conferencia do cliente acontece abaixo, manualmente, na
            // claim certa.
            ValidateAudience = false,

            ValidateLifetime = true,

            // O padrao da biblioteca e 5 minutos. Reduzido para bater com
            // a formula de atraso de revogacao da secao anterior: cada
            // segundo aqui e atraso que voce paga sem ganhar nada, porque
            // os relogios das tasks em Fargate ja sincronizam por NTP.
            ClockSkew = TimeSpan.FromSeconds(30),
        };

        o.Events = new JwtBearerEvents
        {
            OnTokenValidated = ctx =>
            {
                var principal = ctx.Principal!;

                // `token_use` e a claim que a validacao padrao NUNCA
                // confere. Sem isto, um token de IDENTIDADE — que tem
                // assinatura, emissor e expiracao igualmente validos —
                // passaria como credencial de API.
                var uso = principal.FindFirstValue("token_use");
                if (uso != "access")
                {
                    ctx.Fail($"token_use precisa ser access; recebido: {uso}");
                    return Task.CompletedTask;
                }

                // client_id substitui aud no token de acesso. Sem esta
                // checagem, um token de acesso valido emitido para OUTRO
                // app client do mesmo pool passaria tambem.
                var cliente = principal.FindFirstValue("client_id");
                if (cliente != clienteEsperado)
                {
                    ctx.Fail("client_id nao confere com o app client esperado");
                    return Task.CompletedTask;
                }

                return Task.CompletedTask;
            },
        };
    });

builder.Services.AddAuthorization(o =>
{
    // Autenticado != autorizado. O escopo do resource server e quem
    // decide o que este portador pode fazer — o pool so prova quem ele e.
    o.AddPolicy("PedidosLeitura", p =>
        p.RequireClaim("scope", "https://api.ffv-lab.exemplo/pedidos.leitura"));
    o.AddPolicy("PedidosEscrita", p =>
        p.RequireClaim("scope", "https://api.ffv-lab.exemplo/pedidos.escrita"));
});

var app = builder.Build();

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

// Nenhuma linha aqui grava sessao em lugar nenhum. O que autoriza esta
// chamada e o token que chegou NESTA requisicao — a proxima pode cair em
// outra task e o resultado e identico.
app.MapGet("/api/pedidos", async (AppDb db, ClaimsPrincipal usuario) =>
    Results.Ok(await db.Pedidos
        .Where(ped => ped.LojaId == usuario.FindFirstValue("custom:loja_id"))
        .ToListAsync()))
    .RequireAuthorization("PedidosLeitura");

app.Run();

# provas.sh — cinco medicoes; nenhuma conclusao vem de "parece que funcionou"

REGIAO=us-east-1
POOL_ID=$(terraform output -raw pool_id)
CLIENT_ID=$(terraform output -raw client_id)
API="https://$(terraform output -raw dominio)/api/pedidos"

# ── Prova 1: o token de acesso NAO tem aud, o de identidade tem ─────────────
# Pega um par de tokens reais (apos login manual pelo Hosted UI) e decodifica
# so o payload (segundo segmento) de cada um.
echo "$TOKEN_DE_ACESSO"    | cut -d. -f2 | base64 -d 2>/dev/null | jq 'has("aud"), has("client_id")'
echo "$TOKEN_DE_IDENTIDADE" | cut -d. -f2 | base64 -d 2>/dev/null | jq 'has("aud"), has("client_id")'
# Esperado: token de acesso -> false, true. Token de identidade -> true, false.

# ── Prova 2: qualquer task serve qualquer cliente ────────────────────────────
# 200 requisicoes com o MESMO token, contra um servico com 2+ tasks.
for i in $(seq 1 200); do
  curl -s -o /dev/null -w '%{http_code} ' -H "Authorization: Bearer $TOKEN_DE_ACESSO" "$API"
done | tr ' ' '\n' | sort | uniq -c
# Na Cadencia, com stickiness desligada: 200 respostas "200", zero "401" —
# contra ~50% de 401 no desenho minimo com 2 tasks (secao de arquitetura).

# ── Prova 3: token de identidade e recusado como credencial de API ──────────
curl -s -o /dev/null -w '%{http_code}\n' -H "Authorization: Bearer $TOKEN_DE_IDENTIDADE" "$API"
# Esperado: 401. Se vier 200, a checagem de token_use nao esta ativa.

# ── Prova 4: revogar corta a RENOVACAO, nao o token de acesso em curso ──────
INICIO=$(date +%s)
aws cognito-idp admin-user-global-sign-out --user-pool-id "$POOL_ID" \
  --username ana@lojadoze.exemplo --region "$REGIAO"
curl -s -o /dev/null -w '%{http_code}\n' -H "Authorization: Bearer $TOKEN_DE_ACESSO" "$API"
# Esperado: 200 — mesmo apos o sign-out global, o token de acesso em curso
# continua servindo ate expirar. Repita a cada minuto e anote o instante em
# que passa a dar 401: deve bater com "iat + access_token_validity" (15 min).
while curl -s -o /dev/null -w '%{http_code}\n' -H "Authorization: Bearer $TOKEN_DE_ACESSO" "$API" \
    | grep -q 200; do sleep 30; done
FIM=$(date +%s); echo "atraso de revogacao observado: $(( (FIM-INICIO)/60 )) min"

# ── Prova 5: a chave publica e buscada uma vez, nao a cada requisicao ───────
# Compare a duracao da primeira chamada (cache frio) com a media das 50
# seguintes (cache quente) na mesma task, medindo so o tempo de middleware.
curl -s -o /dev/null -w 'primeira: %{time_total}s\n' -H "Authorization: Bearer $TOKEN_DE_ACESSO" "$API"
for i in $(seq 1 50); do
  curl -s -o /dev/null -w '%{time_total}\n' -H "Authorization: Bearer $TOKEN_DE_ACESSO" "$API"
done | awk '{s+=$1; n++} END {print "media das seguintes: " s/n "s"}'
# Na Cadencia: primeira chamada em 0,31 s (inclui buscar o JWKS); as 50
# seguintes em 0,004 s de media — a diferenca e a ida a rede que some.

# limpar.sh — a ordem importa, e dois destes recursos sobrevivem ao destroy

# 1. Derrube o que o Terraform administra.
terraform destroy -auto-approve

# 2. DOMINIO DO HOSTED UI: a liberacao do prefixo NAO e imediata. Se voce
#    tentar recriar com o mesmo nome minutos depois, a criacao falha com
#    "domain already associated" — a AWS ainda esta processando a remocao.
aws cognito-idp describe-user-pool-domain --domain "$PREFIXO_ANTIGO" \
  --region us-east-1 2>/dev/null && echo "dominio ainda em liberacao"

# 3. USUARIOS DO POOL: deletion_protection = ACTIVE bloqueia o destroy de
#    proposito. Sem desligar, o comando 1 falha e tudo o mais fica de pe.
aws cognito-idp update-user-pool --user-pool-id "$POOL_ID" \
  --deletion-protection INACTIVE --region us-east-1

# 4. GRUPO DE LOGS: tem retencao propria e nao pertence ao ciclo do pool
#    nem do servico. Fica cobrando ingestao retida depois de tudo apagado.
aws logs delete-log-group --log-group-name /ecs/ffv-lab-api 2>/dev/null || true

# 5. E o que veio do L01 e do L11 e continua cobrando por hora: ALB, RDS,
#    NAT Gateway e o Elastic IP dele. Se voce nao vai seguir para o L38,
#    rode a limpeza deles tambem.
aws ec2 describe-addresses --query "Addresses[?AssociationId==null].PublicIp" \
  --output table

# 6. Prova final: nada com nome do projeto de pe, e o pool realmente sumiu.
aws resourcegroupstaggingapi get-resources \
  --tag-filters Key=Projeto,Values=ffv-lab --query "ResourceTagMappingList[].ResourceARN" --output table
aws cognito-idp list-user-pools --max-results 20 \
  --query "UserPools[?contains(Name, 'ffv-lab')].Name" --output table