workers and cf access jwt validation
I saw multiple mentions online that users are doing jwt validation in cf workers because they saw the cloudflare docs mentioning you need to validate jwt tokens on your origin when access is used in front of a backend. But as far as i understand workers with access is not comparable to an internet reachable origin but comparable to an internal only cluster with an auth proxy. As neither "private only services behind a security proxy" nor "cloudflare workers with cf access" are reachable without going through the auth proxy they completely delegate security to that proxy and can trust the claims they get. Am i missing anything or is this a valid security assumption?
2 Replies
Yes but you should still verify the jwt so that the communication is cryptographically secure and resistant against any future routing trickery or vulnerability that might bypass this assumption or to prevent misconfigurations leading to an exposed worker a lot easier (e.g. you accidentally add an extra route)
its one part of a layered security approach
thanks for the answer! just to play devils advocate to see if i am understanding the situation: if i cannot trust my entrypoint functions to be configured correctly why would that not apply to any other function in my workers setup? if you take this to the conclusion i would have to assume any worker function is misconfigured and reachable from the internet and thus id have to sign any function argument in any worker.
in addition, if jwt s should be validated, why is cloudflare exposing Cf-Access-Authenticated-User-Email to be used directly? this would communiciate to me as developer that i can trust this information
also i have trouble finding the attack vector. even if a route is misconfigured, cloudflare removes external cf-jwt assertion headers coming in from outside orange cloud for exactly this reason AFAIK
thanks! this makes me wonder why the access data was not exposed via context argument instead of headers which would make this whole class of vulnerabilities obsolete and reduce implementation effort and latency quite a bit.
i will at least cache validation results per signature for the lifetime of a worker
sure but thats a completely different usecase, just because other origins need headers is not an argument to force worker users to do the same work again that was just done by cf access a few ms ago. it should be definitely on the roadmap
will do, curious why not. but i assume the usage of cf access + cf workers is just a tiny fraction of workers. cf access would have to address more of the need for an external end user authentication vs mostly for internal company employee users