Social Login – Pomcor

A Protocol for Social Login in the Age of Mobile

Update. We are no longer calling the proposed protocol SimpleAuth. We are now calling it SAAAM: Simple Authentication and Authorization in the Age of Mobile.

In social login, pioneered by Facebook Connect, a site or application (the client) is granted access to the user's account at a social network (the server). It then learns the identity of the user by accessing the user's profile, and performs operations such as issuing social updates on behalf of the user. This combination of authentication and authorization is a powerful idea, which must be credited with making third-party login popular on the Web at large.

We have now entered the Age of Mobile. Will social login be as successful in the mobile world? It should be even more succesful, since not having to enter a password on a tiny touch-screen keyboard is a great benefit to the user. But there is no standard protocol today that is suitable for native mobile applications. Actually, there is no protocol, standard or proprietary, that covers all four use cases obtained by combining a native or online application in the role of social login client with a native or online application in the role of social login server.

Let's consider each use case in turn:

Native server and native client.
Both the server and the client have created native applications that can be installed in the user's mobile device to serve as front-ends. Both must have online back-ends as well. It is obvious that the server must have a back-end. The client must also have a back-end if it maintains its own user accounts, which I assume is the case by definition for social login.

This case is supported by Facebook as a social login server, with native front-ends for iOS and Android. But there is no protocol that the client can use to login with Facebook via a native Facebook application. Instead, the client front-end must incorporate proprietary code provided by a Facebook SDK into its own code.
Native server and online client.
This is the case where the client is a Web application that the user accesses through a mobile browser, and the server is a social network that has a native front-end installed on the user's mobile device. Since native front-ends are under user control, they cannot be trusted to authenticate the user; hence the client must obtain the user's identity from the back-end of the social network; but the user interface for obtaining user consent should be handled by the native front-end of the social network.

To my knowledge, this case is not supported at all today.
Online server and native client.
This case has been discussed recently on the OAuth 2.0 mailing list [1] (threads Report an authentication issue and proposal of a paragraph to add to the security considerations section). Native clients use the OAuth 2.0 implicit flow to provide social login via Facebook, but the implicit flow allows user impersonation by an attacker who uses a rogue client. Many native clients have been confirmed to be vulnerable [2][3]. Some native clients have addressed the vulnerability using proprietary and undocumented Facebook APIs [4][5].

Several participants in the discussion argued that OAuth 2.0 is not designed or intended for authentication, i.e. for social login. Yet OAuth 2.0 is the protocol that's being used for social login by at least Facebook, Twitter, LinkedIn, Google and Yahoo.

The editor of the OAuth 2.0 specification had this to say [6]:

The sad reality is, we've spent 3 years producing a specification that is less secure, more complex, and does not interoperate the way OAuth 1.0 does.

It does scale better for huge companies like Google, Microsoft, and Yahoo. No wonder they wanted it this way.

When asked, I tend to advise people using OAuth 1.0 to just keep using it.

Oh well.

However, it's not clear how OAuth 1.0 can be used for social login by a native client, since it makes use of a long client secret that could not be stored securely in the native client front-end.
Online server and online client.
This case at least should be covered, shouldn't it? It's not, because OAuth 2.0 relies on the same implicit flow when the client is a Web 2.0 application implemented in JavaScript and running within the browser. And the implicit flow allows user impersonation in this case as in the case of a native client [7].

Another problem of OAuth is that it requires prior registration of the client with the server. Clients can only afford the time and effort it takes to register with a few social networks. Because of this, and because relying on the native front-end of a social network requires incorporating proprietary code provided by an SDK, social login is a feature that only Facebook and other top-tier social networks can offer to their users. Many other social networks out there cannot take advantage of it.

OpenID Connect is an extension of OAuth that tries to fix some of the problems of that protocol, at the cost of extraordinary complexity. OpenID Connect adds six specifications to the already large number of OAuth-related specifications. It solves the user impersonation vulnerability of the implicit flow by introducing another token, the ID Token, in addition to the authorization code and the two kinds of access tokens of OAuth. It tries to solve the prior registration problem with a dynamic registration protocol, but does not provide any practical means of authenticating the client as it registers.

Why is social login such a mess? Is it because designing a secure social login protocol is intrinsically difficult? It's certainly not trivial, but that's not the problem. The problem is the approach that has been followed so far, i.e. start with a pre-Web 2.0 authorization protocol and add layers of complexity to handle social login, Web 2.0 applications, and native applications. The result is not pretty.

What if we started from scratch and tried to design a social login protocol for the Age of Mobile, without being constrained by legacy protocols? We've tried that at Pomcor and we have come up with a preliminary design of a social login protocol that we call SAAAM: Simple Authentication and Authorization in the Age of Mobile [8]. It's much simpler than other authentication or authorization protocols, it supports native applications as client and server front-ends, it does not require prior client registration, and it provides strong security; or at least we think so; please let us know if you find any security glitches or have any other comments.

References

[1]	OAuth Mailing List Archive. http://www.ietf.org/mail-archive/web/oauth/current/maillist.html.
[2]	Rui Wang. [OAUTH-WG] Report an authentication issue, 14 Jun 2012 10:18:16 -0700. http://www.ietf.org/mail-archive/web/oauth/current/msg09270.html.
[3]	Nat Sakimura. Re: [OAUTH-WG] Report an authentication issue, 15 Jun 2012 05:50:50 +0900. http://www.ietf.org/mail-archive/web/oauth/current/msg09273.html.
[4]	Nat Sakimura. Re: [OAUTH-WG] Report an authentication issue, 16 Jun 2012 09:16:42 +0900. http://www.ietf.org/mail-archive/web/oauth/current/msg09316.html.
[5]	Nov Matake. Re: [OAUTH-WG] Report an authentication issue, 16 Jun 2012 12:22:23 +0900. http://www.ietf.org/mail-archive/web/oauth/current/msg09321.html.
[6]	Eran Hammer. Re: [OAUTH-WG] proposal of a paragraph to add to the security considerations section, 21 Jun 2012 14:17:08 +0000. http://www.ietf.org/mail-archive/web/oauth/current/msg09373.html.
[7]	John Bradley. The problem with OAuth for Authentication, January 28, 2012. http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.html.
[8]	F. Corella and K. Lewison. SAAAM: Simple Authentication and Authorization in the Age of Mobile. Revised June 25, 2012. https://pomcor.com/whitepapers/SAAAM.pdf.

A Proposed Architecture for the NSTIC Ecosystem

NSTIC has very ambitious privacy goals. Today's third-party login solutions do not come close to meeting them. Privacy-enhancing technologies that could meet them have yet to be deployed successfully. And Facebook's social login is preempting the password-reduction benefit of NSTIC while severely reducing privacy. Can NSTIC succeed?

We believe that the key to success is to build privacy-enhancing technologies into the fabric of the Web, so that little effort is required of users, relying parties, identity providers and social sites to take advantage of them. In the white paper

A Proposed Architecture for the NSTIC Ecosystem

we propose an NSTIC architecture based on extensions of two core protocols of the Web, TLS and HTTP, and we describe a range of use cases to show how it meets the goals of NSTIC.

The paper is still a first draft, and we hope you'll help us improve it by leaving your comments below.

Altly Needs PKAuth

I was happy to read Dmitry Shapiro's blog post about Altly, a startup that plans to challenge Facebook on privacy grounds. We need competitors to Facebook for all the reasons mentioned by Dmitry, plus a few others.

Facebook uses OAuth to implement social login ("Facebook Connect", now called "Login with Facebook"). OAuth is insecure, because it allows an authorization code to be sent in the clear from Facebook to the relying party (the application or site that features the Login with Facebook button). If you log in with Facebook in a cafe, an attacker may be able to intercept the code and use it to impersonate you.

Another problem with OAuth is that it requires prior registration of the relying party with Facebook. This means that, if Login with Facebook becomes ubiquitous, Facebook will have the unchecked power to effectively disable most Web applications by revoking their registrations.

The registration requirement is also an additional barrier to entry for Facebook competitors such as Altly. To implement "Login with Altly" competitively, Altly will have to persuade over a million sites and applications to register with it.

To address this competitive barrier we have suggested a social login protocol, called PKAuth, that does not require prior registration. We would be happy to work with Altly and any other social site (including Facebook) that would be interested in implementing PKAuth, writing open source libraries for relying parties, and codifying the protocol as a Web standard.

Must the Site know the Application in a Social Login?

I'm back in San Diego after participating with Karen in the Internet Identity Workshop that took place last week in Mountain View. It was a great workshop, with many in-depth discussions of a broad range of topics. The most interesting ones for me were those concerning NSTIC.

I convened the session "How to meet privacy goals of NSTIC" where I presented the contents of the white paper "Achieving the Privacy Goals of NSTIC in the Short Term" and showed companion PowerPoint slides illustrating protocol steps.

There was a lively discussion. One of the points that were debated was whether a Web application that acts as relying party in a social login scenario (e.g. by featuring a button "Log in with Facebook"), could and/or should remain anonymous with respect to the social site (e.g. Facebook). Social login combines authentication and authorization, and the application not only is provided with the user's identity relative to the social site, but also is given a level of access to the user's account at the site.

Some people argued that the social site has to protect the user against malicious applications, and must therefore register applications that want to act as relying parties, so that it can revoke the registration of an application that misbehaves. I argued that the user should be allowed to take responsibility for the applications he or she wants to use, that requiring registration gives the social site too much power over applications, and that the identity of the relying party should not be revealed to the social site as a matter of user privacy.

This is an important debate that will no doubt continue. It highlights the contrast between current technology and one of the privacy goals of NSTIC.

Social Login without Application Registration

Tonight I'm in Washington DC with Karen Lewison for the NIST IDTrust workshop, which takes place tomorrow and the day after (April 6-7). We'll be showing a poster on PKAuth, our proposed social login protocol. By social login I mean the buttons that allow you to log in to Web applications with your identity at a social network such as Facebook, LinkedIn or Twitter, giving the application access to your social context at the site. I believe the term social login was coined by Janrain.

Today social login uses the OAuth protocol, which requires prior registration of the application with the social site. The registration process establishes a shared secret that the site later uses to authenticate the application, and provides the site with information that it later uses to identify the application to the user at it asks permission to grant the application access to the user's social context.

The problem with that is that the social site gains the power to disable the application by revoking its registration. Why is that a problem? Because social login is becoming so popular that the day may come when all applications have to register with the dominant social site (currently Facebook) just to be able to authenticate their users. The dominant social site will then have the power to disable any Web application by revoking its registration. That would be bad for users, for applications, and for the dominant social site itself, which would no doubt face registration by multiple governments.

That's why we are proposing PKAuth. In PKAuth registration is optional. A site will be able to require registration for special applications that need, say, administrative access to the user's account, while not requiring it for others. Applications that only want to delegate user authentication should not have to register.

Instead of registration, PKAuth relies on the Web's public key infrastructure, using the application's ordinary SSL certificate to authenticate the application and identify it to the user.

We have just published a revised version of the PKAuth white paper and I will be talking about other benefits of PKAuth in future posts.