Refresh tokens have a different main goal, in my opinion. They are useful to
allow a log lived durable replacement for username/password. This means the
user's primary credential is not stored in the client. Refresh tokens can be
revoked by the user without requiring password change. They are also always
used over a secure channel, and can fetch a (sometimes much) shorter lived
token used over a clear channel. Yahoo! Messenger and others use a model like
this now. Refresh tokens can also be issued to a particular client requiring
authentication, so are not useful if the client authentication credential is
not also compromised.
They do have the property of anonymity as well, but that's true of both teh
refresh token and access token, so it's not specific to refresh tokens.
-bill
________________________________
From: Anthony Nadalin <tony...@microsoft.com>
To: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org>
Sent: Thursday, August 11, 2011 10:40 AM
Subject: [OAUTH-WG] Refresh Tokens
Nowhere in the specification is there explanation for refresh tokens, The
reason that the Refresh token was introduced was for anonymity. The scenario is
that a client asks the user for access. The user wants to grant the access but
not tell the client the user's identity. By issuing the refresh token as an
'identifier' for the user (as well as other context data like the resource)
it's possible now to let the client get access without revealing anything about
the user. Recommend that the above explanation be included so developers
understand why the refresh tokens are there.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
