Re: [OAUTH-WG] DPoP - Downgrades, Transitional Rollout & Mixed Token Type Deployments

[Brian Campbell <[e-mail]>]

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>
and the now defunct Token Binding
<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>). 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> 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>

  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>] 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>] 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>] and [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 <[e-mail]> 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=> thread,
>    in my opinion inconclusive, no consensus
>
>
> S pozdravem,
> *Filip Skokan*
> _______________________________________________
> OAuth mailing list
> [e-mail]
> 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._