On Wed, Jun 10, 2020 at 4:32 PM Justin Richer <jric...@mit.edu> 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=40lodderstedt....@dmarc.ietf.org> 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/
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
