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

[Francis Pouatcha <[e-mail]>]

On Wed, Jun 10, 2020 at 4:32 PM Justin Richer <[e-mail]> wrote:

> What if we simply declare that *refresh tokens are always bound to the
> DPoP key* used to request them? Is there value in NOT binding the refresh
> token?
>
> Fully agree. I will add a *refresh_token shall always be PoP bound*.
Independent of the type of PoP.


> As for access tokens, the way I read it, all of this is true:
>
> - The AS could still decide to issue a Bearer token, using the token_type
> field, for whatever policy reason.
> - A client getting back a Bearer token from a DPoP request would do Bearer
> headers.
> - A client getting a DPoP token from a DPoP request would do DPoP headers.
> - An client should never send a DPoP token as a Bearer header.
> - An RS should ALWAYS look for a DPoP binding signature from a DPoP scheme
> token. Missing that is an error.
>
> So if we just declare that a refresh token must always be DPoP bound when
> DPoP is used to request it and a refresh token is issued, then we’re in the
> clear here, as best as I can tell, and it allows the AS some flexibility.
>
> Some problems with this:
>
> 1) Pretty much every single OAuth client in the world ignores the
> “token_type” field. But clients being updated to support DPoP wouldn’t
> ignore it, so that’s probably ok.
> 2) If we wanted to make refresh token binding switchable we’d need a
> “refresh_token_type” field or similar, and the client would need to know
> how to understand it and deal with its absence (since most servers won’t
> send it).
> 3) This presumes the client will not rotate its key before using the
> refresh token. If it does it’ll have to do a whole new grant.
> 4) None of this prevents an RS from ignoring the DPoP signature, but I
> think that’s a separate problem.
> 5) It’s arguable that we’d want a client to be able to bind a NEW DPoP key
> during a refresh, using the old key as proof for the refresh token and the
> new key going forward. Is this a case we want to enable?
>
Key rotation shall be handled separately from the refresh_token process. If
a refresh_token is bound to a key, the client shall keep that key till the
refresh_token is consumed. A key rotation process shall be designed such as
to allow the key holder to keep obsolete keys for the completion of pending
processes.

>
>  — Justin
>
> On Jun 7, 2020, at 3:22 AM, Torsten Lodderstedt <
> torsten=[e-mail]> wrote:
>
> That’s correct for confidential clients.
>
> For a public client, the refresh token is just bound to the client id.
> DPoP allows binding to an ephemeral key pair for this kind of clients.
>
>

-- 
Francis Pouatcha
Co-Founder and Technical Lead at adorys
https://adorsys-platform.de/solutions/