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.
> Am 07.06.2020 um 00:57 schrieb Francis Pouatcha > <fpo=40adorsys...@dmarc.ietf.org>: > > >> >> > Am 05.06.2020 um 22:17 schrieb George Fletcher >> > <gffletch=40aol....@dmarc..ietf.org>: >> > >> > 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. >> >> +1 that’s a very useful >> feature_______________________________________________ > AFAIK a refresh_token is always bound. What am I missing here? > -- > Francis Pouatcha > Co-Founder and Technical Lead at adorys > https://adorsys-platform.de/solutions/
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
