Just on one narrow point: On Wed, Oct 16, 2019 at 04:23:56PM +0200, Travis Spencer wrote: > On Sun, Oct 6, 2019 at 3:31 PM Torsten Lodderstedt > > Open: How would one implement sender constrained access tokens in that > > case? I’m asking since the receiving RS obviously has no access to the > > information from the TLS handshake since TLS termination happens at the > > proxy (or even in before the request hits the proxy). The RS would need to > > get provided with the cert fingerprint via a trustworthy header, i.e. the > > RS must be aware of the fact it sits behind a proxy. > > This is unfortunately the typical case even with the mTLS draft. This > is because SSL is almost never terminated by the AS; in my experience, > TLS termination is instead handled by some very fast proxy.[1] In such > cases, the proxy will pass the cert through to the AS in some > undefined HTTP header with some undefined encoding. The mTLS spec > should have defined this IMO, as it prevents interop for a primary use > case -- sender constrained tokens.
It's not clear to me that mTLS should have defined a protocol from proxy to backend; that seems like it could be a fairly generic thing and I know of several people that are working on similar things, to one degree or another. draft-schwartz-tls-lb is the example that I can most easily find in my archives; though it's working with non-TLS-terminating cases, there is probably some commonality with TLS-terminating cases as well. -Ben _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
