Re: [OAUTH-WG] Error Responses in JWT Profile for OAuth 2.0 Access Tokens
Hi Vittorio, I was chatting with Aaron offline about this issue and my concern is the addition of Authentication Information Claims in this spec opens up more interoperability issues that can’t be addressed with just a JWT Access Token spec. OAuth 2.0 AFAIK, doesn’t define any behaviors around resource owner authentication assurance with respect to issuing, introspecting, or presenting access tokens. * Token introspection * Token validation error responses * Token refresh * Client Remediation (oidc defined prompt=login, max_age, and acr_values) * Metadata This spec is defining AS behaviors that are orthogonal to the format and should be available via token introspection for example https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-04#section-2.2.1 The claims listed in this section reflect in the access token the the types and strength of authentication that the authentication server enforced prior to returning the authorization response to the client. Their values are fixed, and remain the same across all access tokens that derive from a given authorization response, whether the access token was obtained directly in the response (e.g., via the implicit flow) or after one or more token exchanges (e.g., obtaining a fresh access token using a refresh token, or exchanging one access token for another via [RFC8693<https://tools.ietf.org/html/rfc8693>]). I was hoping one of the outcomes of this spec was toolkit/sdk interop for clients and resource servers. I don’t see how this possible if all the semantics around requesting, validating, and remediating resource owner authentication assurance is implementation specific. The end-to-end scenarios are not achievable with just OAuth 2.0 which breaks interop. I think there is a real need to define resource owner authentication assurance interoperability for access tokens, but I fear this may require its own spec. -Karl Karl McGuinness Chief Product Architect www.okta.com<http://www.okta.com/> On Mar 25, 2020, at 12:59 PM, vittorio.bertocci=40auth0@dmarc.ietf.org<mailto:vittorio.bertocci=40auth0@dmarc.ietf.org> wrote: This message originated outside your organization. Thanks Aaron! You are right, we could be clearer re:errors. AFAIK the only errors we can rely on from an RS are in RFC6750, and the entire section is about what to look for in an incoming AT to validate, hence it doesn't look like we have much choice but to return invalid_token for every error in the validation checks enumerated in Section 4. I can definitely add a paragraph to that effect (does it have to be a section?). The re-authentication part is tricky. Technically we are still rejecting the incoming token, hence the above should still apply. I am not aware of tools we can use from the primitives defined in the OAuth2 family of standards for telling people how to make reauthentication happen- and making reauth happen can be quite involved. In Azure AD there are semi proprietary mechanisms that can be used to signal the need to repeat authentication, say for triggering a step-up auth, by sending back together with the error response a challenge that can in turn be used by the client to communicate policy requirements to the AS (which is assumed to support OIDC and accept/understand those policies in form of claim). Giving equivalent guidance but relying only on standards seems tricky, especially without making strong assumptions about how auth happens (e.g can we assume OIDC?). To solve this for the profile, I see two main ways forward: A) We warn the reader that it's on them to decide how to signal the reauth requirement from the API to the client, and how to use that in the client to AS subsequent authorization request B) We venture in devising a standard mechanism for propagating errors that require reauth, basically extending RFC6750 with a new use case (perhaps by detailing extra info to be put in WWW-Authenticate?). I can see how B) might be useful in general, but it doesn't seem particularly tied to the fact that the ATs being discussed here are JWTs... hence I'd be inclined to declare it out of scope here, tho I would really love for us to devise a standard solution for it _somewhere_. WDYT? -Original Message- From: OAuth mailto:oauth-boun...@ietf.org>> On Behalf Of Aaron Parecki Sent: Wednesday, March 25, 2020 12:07 PM To: OAuth WG mailto:oauth@ietf.org>> Subject: [OAUTH-WG] Error Responses in JWT Profile for OAuth 2.0 Access Tokens Section 4 talks about validating JWT Access Tokens https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-04#section-4 It has a list of things the RS MUST do when validating a request made with a JWT access token. This section contains phrases like "...and reject tokens..." and "MUST be rejected if...", without clear instructions on *how* to reject this request. For these, I could infer that the
Re: [OAUTH-WG] MTLS vs. DPOP
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 mailto:tors...@lodderstedt.net>> wrote: Am 07.05.2019 um 20:09 schrieb Karl McGuinness 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 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 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
Re: [OAUTH-WG] MTLS vs. DPOP
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”. 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 > 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 >> 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 >> https://www.ietf.org/mailman/listinfo/oauth > > ___ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00
Makes sense that we don’t want to further couple AS and RS with grant types. I’m OK if we want a dedicated claim to establish whether the token is resource owner delegated vs client acting as itself. Subject Type is already a concept in RISC. Just making folks are aware of prior art. https://openid.net/specs/oauth-event-types-1_0-01.html#rfc.section.2.2 https://openid.net/specs/openid-risc-profile-1_0.html#rfc.section.2.1 -Karl On May 6, 2019, at 12:42 PM, Vittorio Bertocci mailto:Vittorio=40auth0@dmarc.ietf.org>> wrote: This message originated outside your organization. Fair enough! What others think about it? Exploring the approach: would we want a bool claim or an enumeration, e.g. sub_type = [ resource_owner | client ] ? On Mon, May 6, 2019 at 12:35 PM Vladimir Dzhuvinov mailto:vladi...@connect2id.com>> wrote: Hi Vittorio, On 06/05/2019 22:22, Vittorio Bertocci wrote: > It is true that the grant_type is a client side consideration. I did think > about the "client_id==sub" heuristic, but that's not always applicable: > many systems have their own rules for generating sub, and in case they want > to prevent tracking across RSes the sub might be generated ad-hoc for that > particular RS. > Would you prefer to have a dedicated claim that distinguish between user > and app tokens rather than reusing grant_type? A dedicated claim to flag client_id effectively == sub would be preferable, and much easier for RS developers to process. The AS is the authority and has all the knowledge to set / indicate this. I want to keep RS developers away from having to deal with grant types and having to make decisions whether client_id effectively == sub. Vladimir > On Mon, May 6, 2019 at 12:16 PM Vladimir Dzhuvinov > mailto:vladi...@connect2id.com>> > wrote: > >> On 06/05/2019 20:32, Vittorio Bertocci wrote: >>> To that end, *Karl MCGuinness suggested that we include >>> grant_type as a return claim, which the RS could use to the same >> effect*. I >>> find the proposal very clever, and the people at IIW thought so as well. >>> What you think? >> The grant type is not something that the RS is really concerned with, or >> should be. Introducing this parameter in the access token will create an >> additional logical dependency, plus complexity - in the system of >> client, AS and RS as a whole, as well as for RS developers. The grant >> type, as a concept, is a matter between the client and AS, and IMO >> should stay that way. >> >> Clear language in the spec should suffice. For instance: "If the sub >> value matches the client_id value, then the subject is the client >> application". >> >> Vladimir >> >> -- >> Vladimir Dzhuvinov >> >> >> ___ >> OAuth mailing list >> OAuth@ietf.org<mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth<https://www.ietf.org/mailman/listinfo/oauth> >> -- Vladimir Dzhuvinov ___ 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
