[ 
https://issues.apache.org/jira/browse/CAMEL-25981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen reassigned CAMEL-25981:
-----------------------------------

    Assignee: Claus Ibsen

> camel-knative - harden the OIDC check of the consumer: compare the token in 
> constant time, read a renewed token, and document the service options
> -------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: CAMEL-25981
>                 URL: https://issues.apache.org/jira/browse/CAMEL-25981
>             Project: Camel
>          Issue Type: Improvement
>          Components: camel-knative
>            Reporter: Claus Ibsen
>            Assignee: Claus Ibsen
>            Priority: Major
>             Fix For: 4.24.0
>
>
> With {{camel.knative.service.oidc.enabled=true}} and 
> {{camel.knative.service.oidc.token.path}}, the Knative HTTP consumer accepts 
> a request only when its Authorization header is "Bearer " followed by the 
> content of the token file ({{KnativeHttpConsumer}}, main e6885df7894d, lines 
> 151-167; since CAMEL-21900). Three things to improve:
> * the header is compared with {{String.equals}}, which is not constant-time: 
> compare the bytes with {{MessageDigest.isEqual}};
> * the token is read once and cached ({{cache.tokens}} defaults to true in 
> {{KnativeOidcServiceOptions}}). After Knative renews the mounted token, the 
> consumer still expects the old one: requests with the new token get 401 until 
> a restart, and the old token is still accepted. Read the token file again 
> when the comparison fails, as the client options do on a 401 
> ({{renew.tokens.on.forbidden}});
> * the service options ({{camel.knative.service.oidc.enabled}}, {{token.path}} 
> and {{cache.tokens}}) are not in the docs, which describe only the client 
> side. Document them, and say that the consumer compares the token with the 
> mounted one: it does not validate it as an OIDC token (signature, issuer, 
> audience, expiry).
> Validating the token as a JWT, with the keys of the issuer, the issuer, the 
> audience of the sink and the expiry, could be a follow-up improvement.
> _Claude Code on behalf of davsclaus_



--
This message was sent by Atlassian Jira
(v10.3.26#10030026)

Reply via email to