OAuth WRAP as next-gen OpenID? (WAS: Problem with nonces and HTTP GET)

[Allen Tom]

I¹m not that familiar with Twitter¹s API, however they turned Oauth into an
Authentication protocol by just implementing an Oauth protected REST web
service that just returns the identity of the user.  After getting the Oauth
Access Token, the client calls the verify_credentials API to figure out who
the user is.

http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-account%C2%A0verify_cr
edentials

Conceptually, the Oauth Access Token is kind of like an Artifact. The actual
data that¹s returned by the verify_credentials API is equivalent to an
Assertion.

With regards to WRAP, I¹d be interested in seeing an OpenID/WRAP Hybrid
Extension. In fact, I think the existing OpenID/Oauth Hybrid is pretty close
to WRAP. All we have to do is get rid of the Access Token secret and all the
Oauth sigs, and we¹d be done. I think this could be used to implement
Artifact Binding.

Allen



On 1/28/10 6:29 AM, "Andrew Arnott" <andrewarnott at gmail.com> wrote:

> Forking thread...
> 
> Hmm.... so my disclaimer here is that I haven't read Nat's spec on artifact
> binding, so perhaps what I'm suggesting is almost the same thing as you've
> already got...
> 
> Allen had mentioned that artifact binding requires sharing state potentially
> across data centers, which is difficult.  And some have mentioned on this
> and/or the general list (I forgot which) that Twitter's OAuth authentication
> is sort of next-gen OpenID (which I've never understood).  But I wonder... if
> we're going with the artifact approach anyway, would using OAuth WRAP make
> sense here?  Consider...
> 
> The RP/consumer sends the user to the IdP/OP/SP to authorize an OAuth WRAP
> token, and the OP sends the user back to the RP with a small message.  The RP
> then requests the authorized token (I forgot the exact terminology here in the
> WRAP spec) from the IdP, and uses that token to request authentication status
> for the authorizing user, along with any attributes the RP needs.  So it's out
> of band, can result in a large response, or whatever.  
> 
> So far, I've not added any value to OpenID+artifact binding. 
> 
> Except that between the authorizing of the token and when the RP finally asks
> for attributes, the IdP hasn't had to store any artifact or state of the user,
> since the WRAP token is self-signed by the token issuer and contains the
> information the RP is allowed to request.
> 
> The OAuth WRAP token MAY still be valid.  Even if for a very short time, it
> would allow the RP to "replay" this token, possibly solving the problem of the
> RP's return_to page being re-fetched (although probably not by itself since
> the RP would still have to know not to re-authorize the token).  But it would
> also allow the RP to auto-log-off the user if the IdP began reporting that the
> user was logged off.
> 
> Just a thought.  But it does seem that OpenID+artifact is a substantial change
> from 2.0, so it's interesting to consider equally large change alternatives
> that are already adopted just in case they make sense.  There's obviously a
> lot here that I haven't discussed or even considered, so feel free to trash
> the idea. :)
> 
> --
> Andrew Arnott
> "I [may] not agree with what you have to say, but I'll defend to the death
> your right to say it." - S. G. Tallentyre
> 
> 
> On Thu, Jan 28, 2010 at 3:02 AM, Nat Sakimura <n-sakimura at nri.co.jp> wrote:
>>  
>> (2010/01/28 16:21), Allen Tom wrote:
>>>   Hi all -
>>>  
>>> Before I get started ­ I agree that in an ideal world, we¹d have full end to
>>> end SSL, old browsers would be banned, and we¹d POST data.
>>>  
>>> However, requiring RPs to support SSL isn¹t going to help adoption and is
>>> deal breaker for most applications that want to use OpenID today.
>>> Encouraging RPs to use SSL is a great idea ­ but it should not be required.
>>>  
>>> Although most browsers can support URLs > 2KB, some proxy servers choke on
>>> URLs > 2KB. This is not fun to debug.
>>>  
>> I add one more thing here: Many mobile browsers choke.
>>> 
>>> In practice, enforcing the nonce only gives the illusion of additional
>>> security. If there¹s a MITM, instead of replaying (or pre-playing) the
>>> assertion, the attacker will just steal the browser cookies instead.
>>> Assertions should have a limited lifetime ­ but this can be enforced by
>>> checking the timestamp and allowing for a narrow replay window.
>>>  
>>> POST is technically the ideal solution, but results in a degraded UX. The
>>> proprietary market leaders have set the bar very high and we need to offer
>>> an open alternative that is just as good, if not better. We really aren¹t
>>> going to get anywhere with a clunky UX.  POST adds additional latency, and
>>> can cause strange warnings and a blank interstitial (the self submitting
>>> form). 
>>>  
>>> I really would like to be able to return an assertion using AX with a lot of
>>> attributes, and Hybrid that can fit within the 2KB limit. This is needed
>>> just to reach parity with the proprietary stuff.
>>>  
>> Artifact Binding :-) Our implementation is returning (for the experiment
>> purpose) assertion that is well over 5MB with AX.
>> 
>> =nat
>>> 
>>> Allen
>>>  
>>>  
>>> 
>>> _______________________________________________
>>> specs mailing list
>>> specs at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs
>>>   
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20100128/1ec1bc61/attachment.htm>