Re: Double-check OpenID/OAuth section?

Thanks! Inline...

On Oct 7, 2010, at 5:49 AM, Harry Halpin wrote:
> Everyone (particularly David, Chris, Eran and others who we've talked
> to aout this)
> 
>   I think these sections are very important, and want to make sure I
> get the tech details right in the final report to the W3C - so if you
> could double-check these ASAP, that would be great!  cheers,
>    harry  (ignore bibliographic markers)
> 
> ===OAuth====
> 
> OAuth (Open Authorization) [OAUTH!!] is an IETF standard lets users
> share their private resources on a resource-hosting site with another
> third-party site without having to give the third-party their
> credentials for the site and so access to all their personal data on
> the social site. This standard essentially defeats the dangerous
> practice of many early social networking sites of accessing for the
> username and password of an e-mail account in order to populate a list
> of friends. Instead, OAuth allows an authorized handshake to happen
> between an resource-hosting site and a third-party, which then lets
> the third-party to redirect the user to authorize the transaction
> explicitly on the original site. If the transaction is explicitly
> authorized, then OAuth generates a duration-limited token for the
> third party that grants access to the resource-hosting site for
> specific resource. OAuth's tokens establish a unique ID and shared
> secret for the client making the request, the authorization request,
> and the access grant. To its huge advantage, this approach works
> securely over ordinary HTTP requests, as client generates a signature
> on every API call by encrypting a unique information using the token
> secret, and the token secrets never leave the sites. However, a
> session-fixation attack was discovered in the original specification
> that allowed a malicious party to save the authorization request and
> then convince a victim to authorize it, giving the malicious party
> access to the victim's resources, but this was fixed by having the
> third-party register with the resource-hosting site, as given in an
> update of OAuth. Recently there has also been a timing attack (using
> the difference of time in "bad" and correct digital signature
> verification to figure out tokens), but this has been addressed by
> having digital signature verification use a constant time.
> 
> While OAuth 1.0 is highly successful, the process of generating and
> managing the various tokens was considered difficult by many
> developers, so the IETF draft standard OAuth 2.0 simplifies the

Really it was the process of generating signatures that was too difficult. Thought OAuth 2.0 also simplifies the number of tokens as well.

OAuth 2.0 also breaks apart various use cases around getting tokens such that each is simpler. OAuth 1.0 tried to force them all into one which made each use case more complex.


> process by relying on TLS. While OAuth 2.0 requires that the
> resource-hosting site use HTTPS rather than HTTP (and is therefore
> backwards incompatible), OAuth 2.0 requires SSL SSL is required for
> generating the token, so signatures are no longer required for both
> token generation and API calls. Decreasing complexity, OAuth 2.0 has
> just a single security token and no signature is required. This has
> led to wider adoption across social networking sites like Twitter.

I'd mention Facebook here as well since we didn't implement 1.0 (and moved our own 1.0 style system to 2.0).


> ==OpenID===
> 
> OpenID centralises the authentication step at an identity provider, so
> that a user can identify themselves with one site (an OpenID identity
> provider) and share their profile data with another site, the relying
> party. A user need only remember one globally unique identity, which
> in OpenID 1.0 was a URI. In the initial OpenID 1.0 specification
> [OPENID-1!!], the identity provider was discovered by following links
> of a HTML page accessed by the OpenID 1.0 URI, and OpenID 2.0 also
> allowed the use of the XRD format. One of the primary findings of the
> OpenID effort was that users were uanble to use URIs to identify
> themselves, and so approaches like Webfinger [WEBFINGER!!] even just
> an e-mail address, as enabled by the Webfinger were developed to allow
> e-mail addresses to be used as identifiers, which has had more
> success.
> 
> Once the OpenID provider is discovered, a shared secret is established
> in between the provider and the relying party, allowing them to share
> data. This is primarly done via an attribute exchange protocol
> [OPENID-ATTR!!], that allows the user to specify what personal data
> should be sent to the relying party. Note that this attribute exchange
> protocol is constrained by the information that can be placed as
> attribute-value pairs inside a URI, which is practically limited to a
> maximum of 1024 characters [@@Check?]. OpenID is currently deployed by
> AOL, Facebook, the Livejournal codebase, Microsoft, Myspace, Google
> (including Blogger), WordPress and Yahoo! (including Flickr). However,
> many larger sites deploy themelves as OpenID identity providers but do
> not function as relying OpenID relying parties, i.e. do not allow
> users to log-in to their site using user credentials from another
> site.

Both Facebook and Google accept OpenID logins. I'd reach out to Eric Sachs and Brian Kissel (cc'd) to get more relevant usage information. Google has been making huge strides in OpenID deployment even in the enterprise.


> As a server-side solution, OpenID and successor technologies have the
> advantage of only relying on server-side HTTP redirects, and so in
> general works independent of browsers. Very seriously, OpenID 2.0
> Authentication does not require relying parties to validate, and so
> has been described as phishing heaven, since it allows any
> OpenID-enabled site to redirect a user to a fake OpenID provider, that
> then steals the user's credentials. While OpenID does not specify the
> credentials needed by the authentication mechanism, very few OpenIP
> providers provide authentication based on certficates or other kinds
> of credentials, but primarily rely on username-password
> authentication. Also, the protocol seems complex to developers,
> requiring 7 HTTPS in general.


> Its creators feel that users are not yet
> using the functionality of OpenID on the scale they would like, and so
> given the similarities between the workflow of OpenID and the success
> of OAuth with developers, now it appears that that the next version of
> OpenID, the work known as OpenID Connect [OPENID-CONNECT!!] starting
> at the OpenID Foundation in 2010, will be built entirely on top of
> OAuth.

This section should really be built out more. Because we now have OAuth 2.0, OpenID Connect can be a thin layer on top of it. One of the major things it brings to OAuth is true decentralization in terms of not needing to pre-register consumer keys and secrets. It will also standardize some basic profile attributes such that they're commonly available across providers. While OpenID 2.0 supporter attribute exchange, it was never implemented in a consistent manner.

Received on Tuesday, 12 October 2010 06:47:38 UTC