On Apr 23, 11:27 pm, Leah Culver <[email protected]> wrote:
> Hi all,
>
> I'd like to keep things as simple as possible for the end user as well as
> the consumer, since consumer applications tend to be less concerned with
> security than service provider applications (and less likely to update their
> apps).
>
> *1. One time only token exchange*
>
> I actually agree with the suggestion to keep the access token endpoint
> one-time only. This means that you only get one chance to exchange a request
> token for an access token.
>
> At the access token endpoint, if the request token has been authorized, then
> an access token is granted. If not, the request token is marked as invalid
> or deleted. This means an attacker would get one shot to exchange the
> request token (unknown if it's authorized or not) for an access token.
> Pretty unlikely chance of success and probably not worth the trouble.
> *
> 2. No callback request parameter
> *
> What about using a callback to guarantee a successful exchange?
>
> I'm a fan of eliminating the callback as a request parameter altogether.
> Allow the consumer to register a callback when they register their
> application. I've been trying to think of a scenario where a consumer would
> want a dynamic callback, but I can't think of anything that can't be dealt
> with (via a redirect) after the OAuth dance is over.
>
> This would require a few changes to the spec and would put the burden on the
> service provider instead of users or consumer apps.
>
This seems like a very sensible starting point for a solution. Good
summary of best approaches & ideas.
But I still have a sense (as Dossy above suggested) that OAuth in its
3-legged form must address the need for an authentication mechanism.
As Eran said in his post, the three pieces: (A) get request token, (B)
authorize request token, (C) get access token need to "all" be
connected. Many of the solutions focus on the B-C connection, and
while that approach keeps the user experience good, it does not
adequately address the need for a A-B authentication match. Anything
after B (during which the user indisputably authenticates w/ the SP)
will be as secure as the SP's authentication mechanism (and good
consumer app design) so needn't (I think) be the main focus here.
The weakness is in the A-B connection. There are numerous ways to
mitigate the risk & I think user experience and security strength are
inversely proportional. Whatever happens, I think the consumer is
going to need to signal to the user that it is about to make contact
with the SP, and either ask for or present a PIN, or a pattern or
picture to remember, etc., that the user has to verify, either to
themselves ("yea that's the same picture I saw") or by typing a short
code/PIN to "authenticate." Surely people are more likely to NOT
complete the steps, but is there really a choice? Perhaps the spec
should just state the need for this piece (while doing the B-C stuff
which has little effect on UX) and leave it to SP's to decide how to
strengthen the A-B leg (and provide say, a few examples from weakest
to strongest).
--peter keane
> Leah
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
