1) You often need to deploy your cloud edge load balancer in TCP mode and handle your own TLS termination if you want client authentication. 2) There are often many intermediates between your edge where client TLS is terminated and your actual service. You need to forward cert context from the edge as protected headers to your AS. 3) It's not easy to use different trust roots per tenant for client authentication. SNI is not supported as a selector via off the shelf solutions and requires a software defined network (SDN) solution.
On the FaaS side client complexity is there especially with OpenSSL bindings 1) https://medium.com/@vaneek/using-mutual-tls-authentication-in-a-serverless-world-3afd19a6fe70 -Karl On May 7, 2019, at 11:17 AM, Torsten Lodderstedt <tors...@lodderstedt.net<mailto:tors...@lodderstedt.net>> wrote: Am 07.05.2019 um 20:09 schrieb Karl McGuinness <kmcguinn...@okta.com<mailto:kmcguinn...@okta.com>>: mTLS has significant challenges at scale in a multi-tenant SaaS deployment on public clouds using modern edge technologies/services. Applications are increasingly being built using Function-as-a-Service/ephemeral workloads as well. Additional complexity increases if you also want to support "bring your own CA”. Can you please share the details of those challenges with us? DPoP enables application level deployment model independent of how one’s edge or runtime is deployed/managed. This is very valuable for SaaS providers. We expect to eventually deploy a DPoP like solution for all client models and not just SPA. -Karl On May 7, 2019, at 10:43 AM, Torsten Lodderstedt <tors...@lodderstedt.net<mailto:tors...@lodderstedt.net>> wrote: Hi, mTLS is dead simple to use, secure, is used and can be used on a broad basis (in contrast to the token binding stuff). I also like the fact it provides both client authentication and sender-constraining. We started the work on DPoP for the simple reason that SPAs don’t work well with mTLS and we want to provide a solution with somehow limited capabilities, e.g. regarding replay protection (see DPoP introduction). If someone asks me for the default solution, it’s simple: use mTLS. And if you build a SPA and want to do really security sensitive things, implement your OAuth stuff and the RS interactions in the backend of your application. DPoP is in a really early stage, let’s see where it will go. best regards, Torsten. On 7. May 2019, at 10:25, Hannes Tschofenig <hannes.tschofe...@arm.com<mailto:hannes.tschofe...@arm.com>> wrote: Hi all, In the OAuth conference call today Vittorio mentioned that some folks are wondering whether DPOP is essentially a superset of MTLS and whether it makes sense to only proceed with one solution rather potentially two. I was wondering whether others in the group have a few about this aspect? Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
