* I'm thinking of a uniformly random 16 byte name right now. Have at it. Cute but missing the point. I don’t have to guess it. YOU have to securely deploy it across your proxy (however many staff), your backend (however many staff), your application developers (however many), and perhaps your diagnosing or debug teams if they are different. And then you must make sure that if ANYONE ever takes a packet trace, or makes a slide out of a sample message, that they don’t disclose the header, such as by showing “here’s how we do OAUTH” at a user group meeting.
* Again, this is a defense in depth measure. A config file is fine. No, it’s not. It’s a multi-party shared secret that isn’t identified as a secret. It’s not defense in depth, it’s a foundation of sand. * irrelevant to the current discussion, which is about how the backend distinguishes security-critical headers that the proxy set from security-critical headers that were sneaked past the proxy by a client (through misconfiguration or parsing bug). The backend must trust the proxy. If you tell the proxy to “use FOOBAR123” as the header of the client certificate, how do you know that the proxy properly provided the client certificate? Pretending that the backend only has to trust *part* of the proxy, because we use a sekrit header value is just that, pretending. Your links to confused deputy and CSRF do not address the issues I raised. * Authenticating the other side of a communication pipe is not sufficient to authenticate the origin of the data contained within those messages. The whole point of a proxy is that it forwards requests from clients. In the face of misconfigurations and parsing bugs the backend cannot distinguish headers that were set by the proxy from headers that were spoofed by the client. *This is the entire problem I have been discussing*. And you believe that configuring a proxy, of which you are skeptical, addresses that concern?
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth