In theory, a service provider could handle a change of consumer
credentials, and continue to accept access tokens that it issued to
that consumer previously. But that seems dangerous. If the consumer
credentials were revealed to an attacker, it seems likely that access
tokens and secrets were also
On Sat, Jan 30, 2010 at 5:32 PM, John Joseph Bachir <
johnjosephbac...@gmail.com> wrote:
> I realize that this wasn't one of the goals of OAuth, and on a
> service-by-service basis it seems reasonable for the onus of security and
> data-management to be
>
Hit the save button too soon on that -- w
Here's my view of why 2-legged OAuth (which "isn't really OAuth") is such a
handy tool to have for a system already using OAuth. Here are some problems
that 2-legged OAuth does *not* have, and a list of other solutions that do
(each assumes best possible implementation on both ends).
- the use
I had a question on OAuth version 1.0a that I’m hoping you could help
me find an answer to:
It looks like to me that in the spec there is no requirement for some
affinity between the Consumer Key/Consumer Secret, and the Access
token.
So here’s the scenario: for some services, Consumer may choose