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
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
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 -- was
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
