On Tue, Apr 28, 2009 at 2:27 PM, Peter Keane <[email protected]> wrote:
> Yes, that's right. What it does (for the sake of the SP) is assert
> "this user on the consumer is indeed the same user that authenticated
> at the SP." Authorization always requires authentication (system
> needs to know "who" it is authorizing).
For OAuth, this relationship is simple. The SP authenticates the user,
but authorizes the consumer-plus-request-token pair. The SP *does not*
authorize an authenticated user at the consumer end. That relationship
is up to the consumer to decide.
Put another way, if TweetCash had been given authorization by many
users to access Twitter accounts, they (TweetCash) could impersonate
any one of those accounts in any way they choose. However, it's a
trust relationship. If TweetCash were to abuse that trust, then
Twitter has the ability to disable their access wholesale (via the
consumer key) or the users have the ability to revoke access on a
case-by-case bases. At no point can Twitter *guarantee* that TweetCash
isn't abusing the trust, but it's probably impossible to do so without
creating an unusable technology, particularly for the sorts of
problems we're trying to solve.
The exploit that we're dealing with is that the consumer has no way to
ensure that the SP has authorized access to the intended party. The
verification token *does* ensure this, since it guarantees that the
person that clicks "Authorize {consumer}" is the same one that is
interacting with the consumer, and that's all we're trying to solve.
OAuth does not, and should not, attempt to authenticate identity
across sites.
b.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"OAuth" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [email protected]
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~----------~----~----~----~------~----~------~--~---
