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> 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 <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=>
>> 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
