Andrea Cosentino created CAMEL-24411:
----------------------------------------
Summary: camel-oauth - stop the route when the OAuth processors do
not authenticate the request
Key: CAMEL-24411
URL: https://issues.apache.org/jira/browse/CAMEL-24411
Project: Camel
Issue Type: Bug
Components: camel-oauth
Reporter: Andrea Cosentino
Assignee: Andrea Cosentino
Fix For: 4.23.0
OAuthBearerTokenProcessor and OAuthCodeFlowProcessor both return normally from
process() on the paths where they do not authenticate the caller, so the
remaining steps of the route still run.
* OAuthBearerTokenProcessor (lines 37-50): when the Authorization header is
absent, or is present but does not parse as "Bearer <token>", the processor
sets CamelHttpResponseCode=400, sets a short body and returns. A
present-but-unusable token, by contrast, propagates the exception thrown by
OAuth.authenticate(). The two cases are handled inconsistently.
* OAuthCodeFlowProcessor (line 72) calls AbstractOAuthProcessor.sendRedirect(),
which only sets a 302 status and a Location header, and then returns. The same
happens in the OAuthException catch path.
grep shows no setRouteStop, no CamelAuthorizationException and no RoutePolicy
anywhere in camel-oauth src/main, so nothing halts the exchange. The
component's own tests use the shape
from("platform-http:/bearer").process(new
OAuthBearerTokenProcessor()).setBody(simple("..."))
where the step after the processor executes and replaces the body that the
processor set.
Proposal: make both no-authentication paths terminate the exchange, matching
the fail-closed pattern already used by OAuthHttpSecuritySupport.reject() - set
the response, call exchange.setRouteStop(true), and use 401 with a
WWW-Authenticate: Bearer challenge (RFC 6750) rather than 400 for the
missing/unparseable credential cases.
This changes the status code returned on those paths and stops route execution,
so it needs an upgrade-guide entry.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
