Subject: [OAUTH-WG] DPoP and refresh tokens

From: Dick Hardt <[email-masked]>
Date: Wed, 28 Oct 2020 13:45:45 -0700

Hello

I was reviewing the latest DPoP draft[1] and saw numerous mentions of using
a DPoP proof for refreshing an access token, but no explicit description of
how to do that, nor an example. Was this intentional?

Perhaps a new section "Refreshing an Access Token"?

Additionally, I can imagine that an AS can improve its security posture by
adding support for DPoP *just* to token refresh and not requiring existing
resource servers to upgrade. Rotating refresh tokens would not be as
critical for public clients using DPoP for token refresh.

Would using DPoP only for token refresh be appropriate? If so, language
describing that would be helpful. :)

/Dick

[1] https://tools.ietf.org/html/draft-fett-oauth-dpop-04
ᐧ

---

From: Brian Campbell <[email-masked]>
Date: Wed, 28 Oct 2020 16:20:20 -0600

I'm currently working on the draft and hope to have a new revision
published relatively soon. Just the other day I made some changes to the
text around RTs with
https://github.com/danielfett/draft-dpop/commit/11d90264bffa0325461e7f8d96311fac44986974
that maybe/hopefully makes some of it more clear? But basically the RTs are
only bound for public clients and the exact mechanism to do it is left up
to the AS. The AS both creates and consumes the RT so however it chooses to
associate the DPoP key with the RT is its own implementation detail.
Getting a new bound access token using an RT is meant to be covered in sec
5 "Token Request (Binding Tokens to a Public Key)" with RT being just one
of the grants that could be presented in the token request in conjunction
with the DPoP proof, and the AS would bind the AT it issues to the key in
that DPoP proof. I'd sort of assumed that would just be understood. But do
you think it (including the recent changes) needs more explanation?

I do think using DPoP only for token refresh (only for public clients
though) would be appropriate, for some cases anyway. This has come up on
the list here previously and the general consensus was also that it'd be
useful. I plan to add some language describing that (and loosening some
language that could be perceived as prohibiting it) but haven't gotten to
that item on the editing todo list yet.

On Wed, Oct 28, 2020 at 2:46 PM Dick Hardt <[email-masked]> wrote:

> Hello
>
> I was reviewing the latest DPoP draft[1] and saw numerous mentions of
> using a DPoP proof for refreshing an access token, but no explicit
> description of how to do that, nor an example. Was this intentional?
>
> _______________________________________________
> 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._

---

From: Dick Hardt <[email-masked]>
Date: Wed, 28 Oct 2020 15:35:13 -0700

Hey Brian

A refresh example would make it more clear, and would also assist in
communicating that DPoP could be used just for refresh.

I see in the updated text that using DPoP with confidential clients is
discouraged. I understand the RT is sender constrained -- but
asymmetric cryptography is much stronger than a shared secret. Why
discourage its use?

ᐧ

On Wed, Oct 28, 2020 at 3:20 PM Brian Campbell <[email-masked]>
wrote:

>> Additionally, I can imagine that an AS can improve its security posture
>> by adding support for DPoP *just* to token refresh and not requiring
>> existing resource servers to upgrade. Rotating refresh tokens would not be
>> as critical for public clients using DPoP for token refresh.
>>
> *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.*

---

From: Brian Campbell <[email-masked]>
Date: Wed, 28 Oct 2020 17:08:31 -0600

Okay, I'll look at adding a refresh example and some additional explanation.

There are client authentication methods that use asymmetric cryptography so
sender-constraining a refresh token with an asymmetric key pair (indirectly
via the client's credentials) is already possible and happening in practice
(JWT client auth and MTLS client auth). Nothing in DPoP is trying to
discourage that. DPoP is just avoiding the added complexity and operational
problems that would come with sender-constraining the RT with two different
mechanisms.