We discussed that confidential clients are not subject to any risks since by definition they already have a unique proof-of-possesion necessary to redeem the refresh token which is already a one-time token.
Phil @independentid www.independentid.com [email protected] > On Nov 23, 2015, at 11:49 AM, Hannes Tschofenig <[email protected]> > wrote: > > Hi all, > > at the Yokohama IETF meeting John gave a presentation about the need to > also secure access and refresh tokens against unauthorized access and > loss, see > https://www.ietf.org/proceedings/94/minutes/minutes-94-oauth > > Unfortunately, this threat has not been documented in the current PoP > architecture draft while other threats have been captured appropriately > (see Section 3 of > https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-05). > > Since we are currently finalizing the work on the PoP architecture > document I wanted to contribute text about this use case: > > ------------------------ > > 3.5. Preventing Loss of Access and Refresh Tokens > > RFC 6749 distinguished two types of clients, namely public and > confidential clients, based on their ability to authenticate securely > with the authorization server. Even with confidential clients there is > the risk, combined with certain deployment choices, that an attacker > gains unauthorized access to access and refresh tokens. If those tokens > are bearer tokens then the adversary can re-use them to gain access to > the protected resource, for example to post messages to a social > networking site to distribute spam. > > With proof-of-possession tokens an adversary not only needs to gain > access to a database where those tokens are stored but it also needs to > retrieve the associated keying material. Assuming that these keys are > stored more securely, for example, in a hardware security module or > trusted execution environment this specification offers an additional > layer of defence. > > Since refresh tokens offer a client the ability to request access tokens > the need arises to also define proof-of-possession functionality for > refresh tokens (unless keys bound to the access token cannot be changed > during the lifetime of the refresh token). > > ------------------------ > > Please let us know what you think about including this text into the > next revision of the PoP architecture document and if you have some > suggestions for improved wording. > > Ciao > Hannes > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
