Huh? We’re not talking about PoP with the resource server.
This is a new issue regarding refresh tokens that John and Hannes are raising. Phil @independentid www.independentid.com [email protected] > On Nov 23, 2015, at 12:11 PM, Justin Richer <[email protected]> wrote: > > Access tokens and refresh tokens provide different attack surfaces. > > The refresh token is *potentially* a one-time-use token, but not necessarily > so. Confidential clients are still subject to having their credentials stolen > across HTTP Basic, but that’s where things like OIDC’s “private_key_jwt” > authentication method come into play. Making the refresh token itself PoP > doesn’t solve that issue alone. > > You can’t use things like that at the resource server because the client, by > design, doesn’t authenticate there. > > — Justin > >> On Nov 23, 2015, at 2:59 PM, Phil Hunt <[email protected]> wrote: >> >> 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 > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
