JwtAuthFilter: switch to eager 401 on missing/invalid token, opt-out via @PermitAll

[Yicong-Huang]

What happened?

common/auth/src/main/scala/org/apache/texera/auth/JwtAuthFilter.scala silently passes through any request whose Authorization: Bearer … header is missing or whose token fails verification. No SecurityContext is set; the request continues to the resource method.

This drifts from the toastshaman-based path (amber/.../web/auth/JwtAuth.scala), which returns 401 immediately from the filter with a WWW-Authenticate: Bearer realm="…" challenge. RFC 6750 §3 also expects an explicit Bearer challenge, with error="invalid_token" distinguishing "your token is bad" from "you didn't authenticate at all".

The lazy-401 path also obscures the failure mode in logs (no warning is emitted on missing header), and routes auth signaling through Dropwizard's @Auth parameter binder rather than the filter itself, so invalid-token attempts are not surfaced server-side.

How to reproduce?

1. Start any microservice (e.g. access-control-service).
2. curl -i http://localhost:<port>/api/<auth-protected-endpoint> (no Authorization header).
3. Observe: the request reaches the filter (JwtAuthFilter.filter called), but no WWW-Authenticate header is set on the response and the 401 (if any) only comes from @Auth injection — not from the filter.
4. curl -i -H "Authorization: Bearer not-a-real-jwt" http://localhost:<port>/api/<auth-protected-endpoint>.
5. Observe: the filter logs Invalid JWT: Unable to parse token and continues without aborting; the eventual 401 (again from @Auth injection) lacks WWW-Authenticate.

Branch

main

Commit Hash (Optional)

786a920 (post #4896)