I don't follow the reasoning about all resource servers needing to be updated to support the new scheme before deployment could start. Given how 6750, JWT and Introspection define things (basically as extensible with unrecognized stuff to be ignored) , I would expect that a existing regular RFC 6750 protected resource with no knowledge of DPoP would almost certainly accept a dpop/jkt bound access token as though it was a bearer token. The definition of the DPoP token_type would prescribe sending the access token with the DPoP authorization scheme in conjunction with the DPoP header but also say that, if that was met with a 401 WWW-Authenticate: Bearer challenge (or the client had prior such knowledge about the RS), that the access token could be sent using the Bearer authorization scheme. And would work as such. There may well be some existing protected resources that wouldn't accept a dpop/jkt bound access token but I'd say they'd be operating erroneously and I would think it'd be a pretty small minority - DPoP not defining a new token_type wouldn't change that situation at all anyway. In fact, from the perspective of interoperability on roll out, I don't see how DPoP defining a new token_type or not changes anything. Things look a little more intentional with a new token type and auth scheme and there might be an additional 401 challenge at first with a Bearer only RS but I don't see how the actual inerop is any different.
The suggestion/proposal during the interim to signal to the client that the RT had been bound was indeed to introduce a new token endpoint response parameter[1]. Although I had an intentionally ridiculous name there to serve as a placeholder and hopefully avoid bikeshedding the name. I will say that doing something general (like an rt_token_type) in a specific extension like DPoP can be pretty problematic so I think it should need to be something DPoP specific even if that's a little ugly. [1] slide #23 https://datatracker.ietf.org/meeting/interim-2020-oauth-09/materials/slides-interim-2020-oauth-09-sessa-dpop.pdf On Fri, Jun 5, 2020 at 2:17 PM George Fletcher <gffletch= 40aol....@dmarc.ietf.org> wrote: > The issue I see with sticking with the DPoP token_type is that from a > roll_out perspective, ALL resource > servers must be updated to support the new scheme and only then can the > DPoP deployment start. > For any wide ecosystem deployment that can be problematic. I don't have any > great suggestions:( > > Secondly, I do think we need a way to allow for the refresh_token to be > bound while leaving the > access_tokens as bearer tokens. This adds useful security without impacting > existing RS deployments. > It was unclear from our interim meeting discussion how the client knows > whether the refresh token has > been bound to the public key or not. The AS can signal that the > access_token is NOT bound by > returning a token_type of "bearer" but we should think about adding > addition response fields for > the refresh token binding (e.g. "rt_token_type). > > Thanks, > George > > On 5/29/20 5:50 PM, Brian Campbell wrote: > > Apologies for the slow reply on this. No excuses other than life > > sometimes happens. > > `token_type` is maybe not the clearest extension > point (and one I've > arguably misused in OAuth MTLS > > <https://www.rfc-editor.org/rfc/rfc8705.html> > <https://www.rfc-editor.org/rfc/rfc8705.html> and the now defunct > Token > Binding > <https://tools.ietf.org/html/draft-ietf-oauth-token-binding-08> > <https://tools.ietf.org/html/draft-ietf-oauth-token-binding-08>and > > admitted to being on the fence about in the issue you linked to > > <https://github.com/danielfett/draft-dpop/issues/41> > <https://github.com/danielfett/draft-dpop/issues/41>). But it is the > > extension point that was basically left in RFC 6749 to facilitate > this > exact kind of thing (for MAC really but it's conceptually > similar in that > it was an application level proof mechanism of sorts) > . The text from RFC > 6749 sec 7.1 > <https://tools.ietf.org/html/rfc6749?#section-7.1> > <https://tools.ietf.org/html/rfc6749?#section-7.1> is also copied > > below. Note that a "client MUST NOT use an access token if it does > not > understand the token type" so FWIW the client behaviours you > describe > aren't in line with that. > > It still seems to be that using DPoP > token_type is the appropriate > thing to do and that it can be defined to > account and allow for mixed > token type situations. It would define that > the DPoP authz scheme be > used as the authentication method to include the > access token when > making a protected resource request. That definition > can also include > falling back to using the Bearer authz scheme when/if so > challenged > by a protected resource. > > > <https://tools.ietf.org/html/rfc6749?#section-7.1> > <https://tools.ietf.org/html/rfc6749?#section-7.1> > > 7.1 > <https://tools.ietf.org/html/rfc6749?#section-7.1> > <https://tools.ietf.org/html/rfc6749?#section-7.1>. Access Token > Types > > > The access token type provides the client with the information > > required to successfully utilize the access token to make a > protected > resource request (along with type-specific attributes). > The client MUST > NOT use an access token if it does not understand the > token type. > > For > example, the "bearer" token type defined in [RFC6750 > > <https://tools.ietf.org/html/rfc6750> > <https://tools.ietf.org/html/rfc6750>] is utilized by simply > including > the access token string in the request: > > GET /resource/1 HTTP/1.1 Host: > example.com Authorization: Bearer > mF_9.B5f-4.1JqM > > while the "mac" > token type defined in [OAuth-HTTP-MAC > > <https://tools.ietf.org/html/rfc6749?#ref-OAuth-HTTP-MAC> > <https://tools.ietf.org/html/rfc6749?#ref-OAuth-HTTP-MAC>] is > utilized > by issuing a Message Authentication Code (MAC) key together > with the > access token that is used to sign certain components of the > HTTP > requests: > > GET /resource/1 HTTP/1.1 Host: example.com Authorization: > MAC > id="h480djs93hd8", nonce="274312:dj83hs9s", > > mac="kDZvddkndxvhGRXZhvuDjEWhGeE=" > > The above examples are provided for > illustration purposes only. > Developers are advised to consult the > [RFC6750 > <https://tools.ietf.org/html/rfc6750> > <https://tools.ietf.org/html/rfc6750>] and [OAuth-HTTP-MAC > > <https://tools.ietf.org/html/rfc6749?#ref-OAuth-HTTP-MAC> > <https://tools.ietf.org/html/rfc6749?#ref-OAuth-HTTP-MAC>] > > specifications before use. > > Each access token type definition specifies > the additional > attributes (if any) sent to the client together with the > > "access_token" response parameter. It also defines the HTTP > > authentication method used to include the access token when making a > > protected resource request. > > > > On Tue, May 19, 2020 at 7:20 AM Filip > Skokan <panva...@gmail.com> <panva...@gmail.com> > wrote: > >> This is a > RE: to yesterday's interim meeting discussion, largely >> related to the > first rollout step where we want to constrain >> refresh tokens but leave > protected resource access intact. >> >> I'll start off with a case that I > hope we can agree is absolutely >> necessary for DPoP to solve - that is > constraining refresh tokens >> for browser based applications. Now, *do we > see this as a >> secondary objective? I think it should be on par with > access token >> constraining.* SPAs using code flow and having access to > refresh >> tokens as means against the continuous browser efforts to cut > down >> on storage access is a real case servers will be eventually forced > >> to adopt. >> >> Since rollout for DPoP needs to begin with the AS and > Client >> supporting it (regardless what order i guess) there are going to > be >> instances where the RS will be supporting both Bearer and DPoP at >> > the same time. >> >> As discussed yesterday, the client shouldn't know/care > and change >> its behaviour when it comes to using access tokens. >> >> > *But what is the client behaviour we take for standard?* Because I >> can > see two conflicting implementations in the wild >> >> 1. The client echoes > the token_type it received from the token >> endpoint as the authorization > scheme - (optionally) throws on >> unrecognized token type values 2. The > client uses Bearer as a fixed >> authorization scheme and ignores the > token_type it received >> >> #2 is an implementation which I suspect has no > idea about DPoP, but >> if extended to send DPoP headers (through various > mechanism - >> library extensions or even manipulating the `XMLHttpRequest` > >> prototype) will >> >> - 🎉 get the benefit of having its Refresh Tokens > bound - 🎉 most >> likely continue to work with RSs that only support > Bearer - ❌ will >> cease to work with RSs that will adopt support for DPoP > because >> it'll be using the wrong scheme, that is unless (🎉) RSs >> > supporting DPoP choose to suspend the requirement to use the new >> scheme > and instead depend on the presence of `cnf.jkt` as means to >> trigger DPoP > validation. *Q: is that an acceptable thing to do?* >> >> Arguably, client > behaviour #1 is what a client should be using if >> it supports other > schemes besides Bearer. But it may as well be the >> behaviour of a client > that has no clue about DPoP, right? Again, >> such client can be made to > support DPoP in a SPA through >> manipulation of the XMLHttpRequest > prototype, in which case the >> developer needs to do the same for the > protected resource calls. >> But at this point the developer has to know > which RS to apply DPoP >> to and which not - ergo - which to send Bearer > vs. DPoP scheme to? >> The developer will have to write a whitelist of > resource servers >> anyway - and there we get to the point where client has > >> information and functionality that it shouldn't /need to/ have. >> >> > Its great that we have token_type, authorization header schemes, >> etc...., > but we don't seem have a well defined (or at least >> followed) behaviour > for our clients around handling the token_type >> response values and their > usage. >> >> A developer has to resolve to navigate this monkey course > unless >> the RS definition on the AS is aware of the fact that the RS does > >> support DPoP, so that the issued token_type is always correct for >> the > RS. So, *should we make that a recommended way of 'indicating' >> when to > issue Bearer vs DPoP access tokens?* >> >> What else could we do that > doesn't give more decision making to >> the clients so that the very first > step - *Refresh Tokens get >> constrained* - is achieved* but Protected > Resource access is >> unaffected?* >> >> Note that this was not "a thing" > for mTLS because it continues to >> use the Bearer scheme (for better or > worse) and it completely omits >> possible continuous rollout or discussing > what are the signals the >> RS must use to require mTLS to be used), same > for the abandoned >> OAuth 2.0 Token Binding draft (also continued to use > the Bearer >> scheme). >> >> I suspect we have just this opportunity to fix > token types and >> their use and if we can't, we'll have to resolve to > abandon that >> extension point as one that doesn't support continued > rollout of >> real sender constraining mechanism (e.g. http signatures in > the >> future) and just continue using Bearer because in the end, given >> > that RSs could be relying on the presence of the cnf claim to >> figure out > the token's constraining mechanism, would that be such a >> bad thing? >> > >> Put it the other way around. By introducing Bearer scheme, do we >> > actually gain anything of value that can't be gained through other >> > means? >> >> Note that this message didn't start with the goal of > questioning >> the new scheme use, it just sort of landed there... My > pedantic >> nature would love to see the new scheme and token_type > extension >> point used as it was meant to be but I also recognize the many > >> issues it brings that could be sidestepped by not introducing it in >> > the first place, all without losing capabilities. >> >> Previous material > on the topic >> >> - https://github.com/danielfett/draft-dpop/issues/41, > decision to >> break backwards compatibility amongst the authors - ML >> > <https://mailarchive.ietf.org/arch/browse/oauth/?q=%22DPoP%20-%20new%20authorization%20scheme%20%2F%20immediate%20usability%20concerns%22&gbt=1&index=> > <https://mailarchive.ietf.org/arch/browse/oauth/?q=%22DPoP%20-%20new%20authorization%20scheme%20%2F%20immediate%20usability%20concerns%22&gbt=1&index=> > >> thread, in my opinion inconclusive, no consensus >> >> >> S pozdravem, > *Filip Skokan* >> _______________________________________________ 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 > -- _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
