Hi, I have a question about somewhat of an edge case: can a token be both mTLS and DPoP bound?
Section 3.1 of RFC 7800 ( https://www.rfc-editor.org/rfc/rfc7800.html#section-3.1) says: The "cnf" claim value MUST represent only a single proof-of- possession key; thus, at most one of the "jwk", "jwe", and "jku" (JWK Set URL) confirmation values defined below may be present. Note that if an application needs to represent multiple proof-of-possession keys in the same JWT, one way for it to achieve this is to use other claim names, in addition to "cnf", to hold the additional proof-of- possession key information. So I'd tend to say no? (i.e. a token is either mTLS-bound or DPoP-bound, but not both) In my library for resource servers, I'm currently checking both, and it doesn't cost much to do so, but I'm wondering if I'm doing it right. Currently, for tokens received with the Bearer auth-scheme, I check if "cnf" in the introspection response has a "x5t#S256" member, and also that does NOT have a "cnf"."jkt" (meaning it should have been sent as DPoP). For tokens received with the DPoP auth-scheme, I first check the "cnf"."jkt", then I'll also check the "cnf"."x5t#S256". Should I remove that second check assuming it won't ever happen? or would you say it could be safer to keep it "just in case"? (e.g. in case some AS decides to use both) or should I remove it because some AS could decide to return both but expecting DPoP-supporting RS would only check "cnf"."x5t#S256" (and NOT mandate mTLS), while non-DPoP-supporting but mTLS-supporting RS receiving the token with the Bearer auth-scheme would mandate mTLS then? Or would you advise to just make it configurable? (but even then, what should the default behavior be?) TIA -- Thomas Broyer /tɔ.ma.bʁwa.je/ <https://ipa-reader.com/?text=t%C9%94.ma.b%CA%81wa.je&voice=Mathieu>
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
