Hands-on 3 — Segurança

Quem é você, e o que você pode fazer?

• Autenticação: verificar quem é o usuário → após o login, emitir um JWT assinado, válido por tempo limitado.
• Autorização: verificar o que o usuário pode acessar → o Gateway confere o JWT antes de rotear.
• Um ponto único de entrada: os serviços atrás dele nunca veem uma requisição não autenticada.

Três novos módulos

internet → gateway → account / auth / others · auth → account · tudo dentro da camada confiável

Mesmo padrão de account / account-service: uma biblioteca instalada com mvn clean install, mais um serviço executável.

JSON Web Token

Três partes em Base64Url separadas por pontos: header.payload.signature

HMAC( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret )

• Header: tipo do token e algoritmo de assinatura.
• Payload: as claims — declarações sobre o usuário.
• Signature: prova que o token foi emitido por quem tem o segredo e não foi alterado.
• Stateless: sem sessão no servidor, então escala horizontalmente.

As claims que esta plataforma usa

Mais uma claim personalizada (privada): email. O payload é só codificado, não criptografado — qualquer um pode lê-lo.

O contrato auth

@FeignClient(name="auth", url="http://auth:8080") · nome do cookie AUTH_COOKIE_TOKEN = "__store_jwt_token"

auth-service

store:
  jwt:
    secretKey: ${JWT_SECRET_KEY:EBwrdOOcAIDRLON9hbJV0+O3PTdfTjgMCQIxwLH7ws8=}
    httpOnly: ${JWT_HTTP_ONLY:true}
    duration: ${JWT_DURATION:3600000} # 1 hour in milliseconds

JwtService.generate

public String generate(AccountOut account, long duration) {
    Date now = new Date();
    return Jwts.builder()
        .id(account.id())
        .issuer("Insper::PMA")
        .claims(Map.of("email", account.email()))
        .signWith(getKey())  // Keys.hmacShaKeyFor(Base64-decoded secretKey)
        .subject(account.name())
        .notBefore(now)
        .expiration(new Date(now.getTime() + duration))
        .compact();
}

JwtService.getId

public String getId(String jwt) {
    try {
        JwtParser parser = Jwts.parser().verifyWith(getKey()).build();
        // checks the signature, nbf and exp: a JwtException otherwise
        Claims claims = parser.parseSignedClaims(jwt).getPayload();
        return claims.getId();
    } catch (JwtException e) {
        throw new ResponseStatusException(
            HttpStatus.UNAUTHORIZED, "Invalid token");
    }
}

É isso que o /auth/solve executa: um token válido vira um idAccount; um inválido ou expirado, um 401 (não um 500).

Rotas abertas: RouterValidator

Sem rotas abertas, ninguém conseguiria fazer login.

private List<String> openApiEndpoints = List.of(
    "POST /auth/register",
    "GET /auth/logout",
    "POST /auth/login");

public Predicate<ServerHttpRequest> isSecured = request ->
    openApiEndpoints.stream().noneMatch(/* method and path match, /** = prefix */);

O Gateway decide: AuthorizationFilter

Um GlobalFilter: toda requisição passa por ele antes do roteamento.

1. isSecured? Não → encaminha como está.
2. Cookie __store_jwt_token presente? Não → 401 Unauthorized.
3. POST http://auth:8080/auth/solve com { "token": jwt }.
4. Token inválido → 401. Válido → adiciona o header e encaminha:

Um id-account enviado pelo cliente é descartado antes (RemoveRequestHeader): ninguém se passa por outra conta.

AuthorizationFilter.filter

public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
    ServerHttpRequest request = exchange.getRequest();
    if (!routerValidator.isSecured.test(request)) {
        return chain.filter(exchange);
    }
    if (request.getCookies().containsKey(AUTH_COOKIE_TOKEN)) {
        String token = request.getCookies().getFirst(AUTH_COOKIE_TOKEN).getValue();
        if (null != token && token.length() > 0) {
            return requestAuthTokenSolve(exchange, chain, token.trim());
        }
    }
    throw new ResponseStatusException(HttpStatus.UNAUTHORIZED);
}

O Spring Cloud Gateway é reativo (WebFlux): o filtro devolve Mono<Void> e chama o auth com WebClient, não com RestTemplate.

Teste

docker compose up -d --build

curl -X POST http://localhost:8080/auth/register -H "Content-Type: application/json" \
  -d '{"name": "Antonio do Estudo", "email": "acme@insper.edu.br", "password": "123@321"}'

curl -c cookies.txt -X POST http://localhost:8080/auth/login -H "Content-Type: application/json" \
  -d '{"email": "acme@insper.edu.br", "password": "123@321"}'

curl -b cookies.txt http://localhost:8080/accounts   # 200 — cookie sent
curl http://localhost:8080/accounts                  # 401 — no cookie

Pontos-chave

1. A autenticação emite um JWT assinado; a autorização o confere a cada requisição.
2. Um JWT é header.payload.signature; a chave secreta é o que o torna confiável.
3. O JwtService assina com jti, sub, iss, nbf, exp — e valida a assinatura, nbf e exp.
4. O token viaja em um cookie HttpOnly e Secure: __store_jwt_token.
5. RouterValidator: só cadastro, login e logout são abertos — protegido por padrão.
6. O AuthorizationFilter resolve o token via /auth/solve e repassa o id-account.
7. Os serviços seguintes nunca interpretam JWTs: o Gateway faz isso uma única vez.