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

From: Filip Skokan <[email-masked]>
Date: Tue, 19 May 2020 15:19:18 +0200

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*

---

From: Brian Campbell <[email-masked]>
Date: Fri, 29 May 2020 15:50:13 -0600

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 <[email-masked]> 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.
>
> *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
>    - ❌ 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?*
>
> 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?*
>
>    - 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,
> _______________________________________________
> OAuth mailing list
> [email-masked]
> 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._