Tag: single sign on

Implementing OAuth 2.0

Joss Winn / / ICT, Open Source, Projects, Standards & Specs, Web

One of the lasting outcomes of our Total Recal ‘rapid innovation’ project in 2010, was that Alex Bilbie wrote the first (and only) OAuth 2.0 server for the CodeIgniter PHP development framework that we use. Since then, he’s been refining it and with every new project, we’ve been using it as part of our API-driven approach to development. As far as we know, the use of the OAuth 2.0 specification, which should be finalised at a forthcoming IETF meeting, is not yet being used by any other university in the UK. There are a few examples of OAuth revision A in use, but OAuth 2.0 is a major revision currently in its 23rd draft.

As a result of his work, Alex was invited to talk about OAuth 2.0 at Eduserv’s Federated Access Management conference last year.

OAuth 2.0

View more presentations by Alex Bilbie

Nick Jackson gave the same presentation at the Dev8D conference a couple of weeks ago.

Since Total Recal, we’ve used OAuth 2.0 for Jerome, data.lincoln.ac.uk, Zendesk, Get Satisfaction, and more recently Orbital and now ON Course.  We’re at the stage where our ‘single sign on’ domain https://sso.lincoln.ac.uk is the gateway to our OAuth 2.0 implementation and it will soon be running on two servers for redundancy. In short, due to various JISC projects helping pave the way, it has been formally adopted by central ICT Services, and staff and students are gradually being given control over what services their identity is bound to and what permissions those services have.

Single Sign On at Lincoln
Single Sign On at Lincoln

The work Nick is doing on the Orbital project is extending Alex’s OAuth 2.0 server to include some of the optional parts of the specification which we’ve not been using at Lincoln, such as refresh tokens and using HTTP Authentication with the client credentials flow. This means that the server is able to drop straight in to a wider range of projects and services.

Recently, JISC published a call for project proposal around Access and Identity Management (AIM), which I am starting to write a bid for. Appendix E1 states:

JISC is particularly interested in seeing innovative and new uses for OAuth. Bids should show how this technology brings benefits to the community and can help address institutional requirements within research, teaching and learning, work based learning, administration and Business Community Engagement.

In Total Recal, we released version 1 of the server code but have learned a lot since that project through integrating OAuth with other services. Version 2 of our OAuth server is more representative of our current implementation and fully implements the latest draft (23) of the specification.

However, this is what access and identity management currently looks like:

SSO Current Situation
SSO Current Situation (click the image)

At the moment, the most widespread use of the OAuth server is Zendesk, our ICT and Estates online support service. Projects such as Jerome, Orbital, and ON Course, as well as three 3rd year Computer Science student dissertation projects are using it, too. The plan is to use OAuth alongside Microsoft’s Unified Access Gateway (UAG), which can talk SAML to OAuth via the OAuth SAML 2.0 specification. Here’s what we intend to do:

SSO Ideal Situation
SSO Ideal Situation (click image)

The primary driver for this is the ‘student experience’ and it cuts three ways:

  1. Richer sharing of data between applications: A student or lecturer should be able to identity themselves to multiple applications and approve access to the sharing of personal data between those applications.
  2. A consistent user experience: What we’re aiming for at first is not strictly ‘single sign on’, but rather ‘consistent sign on’, where the user is presented with a consistent UX when signing into disparate applications.
  3. Rapid deployment: New applications that we develop or purchase should be easier to implement, plugging into either OAuth or the UAG and immediately benefiting from 1) and 2).

Following a recent meeting between ICT and the Library, we agreed to take the following steps:

  1. All library (and ICT) applications that we operate internally must have Active Directory sign-in instead of local databases. Almost all of our applications achieve this already. This is the first step towards step (3).
  2. All web-based applications must offer a consistent looking sign-in screen based on the sso.lincoln.ac.uk design (which uses the Common Web Design). This is the second step towards (3).
  3. All systems must implement web-based single sign on via OAuth, SAML or ADFS and they will be sent to either UAG or the OAuth/SAML server.

The library are going to investigate to what extent we can do (2) with their applications such as Horizon and EPrints, and from then on, systems that are purchased or updated must do (3). It also makes sense to look at EPrints and WordPress in the short-term as applications that can use OAuth.

Two of the outputs we’ll propose to JISC are a case study of this work, as well as further development of the open source server Alex and Nick have been developing including an implementation of the OAuth SAML specification that we’ll share. Like our related work on staff profiles, the need to get access and identity right is becoming increasingly apparent as staff and students become accustomed to the way access and identity works elsewhere on the web. For Lincoln, a combination of OAuth and UAG is the preferred route to achieving consistent sign on across all applications, bridging both the internally facing business applications managed by ICT (e.g. Sharepoint, Exchange, Blackboard) and the more outward facing academic and social applications such as those developed and run by the Library and the Centre for Educational Research and Development.

Facebook’s transparent use of OpenID

Joss Winn / / Identity, Standards & Specs, Web

There was a bit of excitement last month when Facebook became an OpenID relaying party. Many of the big names such as Yahoo!, Google, MySpace, etc. have long been providers of OpenIDs to their users, but Facebook is now accepting third-party OpenIDs as a way to login to their site. What’s even more unusual and why I’m writing this post is that it wasn’t until a couple of days ago that I noticed how they’d implemented OpenID:

Existing and new users can now link their Facebook accounts with their Gmail accounts or with accounts from those OpenID providers that support automatic login. Once a user links his or her account with a Gmail address or an OpenID URL, logs in to that account, then goes to Facebook, that user will already be logged in to Facebook.

I don’t think this brief explanation on the Facebook developer blog does justice to how this works in practice. What it means is that if you link your Facebook account to your OpenID, you will automatically be logged in to Facebook if you are logged into your OpenID provider and visit http://facebook.com On any other OpenID enabled site, you click a button or type your OpenID into a login box and are then logged in to the site you’re visiting.

With Facebook, they’ve done away with the need to enter your OpenID credentials altogether. If you’re logged in to your OpenID provider, pause for three seconds on http://facebook.com and you’ll be automatically logged in. If you log out of Facebook and then visit http://facebook.com, you’ll be automatically logged in again. It doesn’t seem to work if you visit any other Facebook URL.

So, for example, if you link your Google account to your Facebook account and, like many of us, are logged in to Google throughout the day using GMail, Google Reader, Google Docs, Google Calendar, or whatever, you never have to think about logging in to Facebook. It’s the closest to a transparent single-sign-on across consumer/social sites that I can think of.

I exchanged a few comments about this with Paul Walk on Twitter, who is less impressed by this than I am. What if you want to log out of Facebook? Really log out? You’d need to log out of your OpenID provider. What if you want to stay logged in to your OpenID provider but log out of Facebook? Why would you want to do that? For most users, I can’t think of a reason. Occasionally I want to log out of a site and ensure I’m completely logged out because I’m testing something. When that happens, I open a different browser, clear cookies and/or use the private browsing mode in Safari or Chrome. The benefits to Facebook’s approach seem to outweigh the occasions when I’d want to do this.

Other than habit, can you think of a reason why you’d want to log out of Facebook but remain logged into your OpenID provider?

Surely what’s important here is whether you are logged in to the world-wide-web or logged out of the world-wide-web. It would be more secure, surely, to know if you were logged in or logged out rather than whether you were logged in to some sites and logged out of others. If I lock my front door, I know that every room in my house has been secured. I don’t need to lock every room in the house, too. When I unlock my front door, I have the freedom to move around my house. And so do guests. This is where single-sign-on becomes potentially dangerous, because it opens up multiple services that have been otherwise protected by multiple authentication credentials. If someone else uses your browser, they have access to all your accounts. That could be useful when you and your partner share accounts on some websites, but dangerous if you leave your PC unattended or have your laptop stolen from a public library.

However, I imagine that most people on the web are using one or two weak passwords across the web services they use because they can’t remember multiple login details. Surely one good password to protect multiple accounts which is used to log in and out of multiple services is better than one or two weak passwords that are used everywhere? If I have one ‘key’ that works everywhere, I’m more likely to get into the habit of using it than I am if I have to remember to log out of multiple sites.

I know of three important blog posts about Facebook’s use of OpenID, two from Luke Shepard, the principle developer of OpenID on Facebook and another from Simon Willison. A month before Facebook implemented their ‘linked accounts’ feature, Luke Shepard was discussing some ideas about OpenID login on his blog. Now that OpenID login to Facebook has been implemented, he’s been discussing the logout process. Following on from these two posts, Simon Willison provides a key overview to the current implementation in light of the new Facebook username feature:

At any rate, their consumer implementation is fascinating. It’s live right now, even though there’s no OpenID login box anywhere to be seen on the site. Instead, Facebook take advantage of the little known checkid_immediate mode. Once you’ve associated your OpenID with your Facebook account (using the “Linked Accounts” section of the settings pane) Facebook sets a cookie remembering your OpenID provider, which persists even after you log out of Facebook. When you later visit the Facebook homepage, a checkid_immediate request is silently sent to your provider, logging you in automatically if you are already authenticated there.

It’s brilliant (well, I think so), to see how a seemingly minor part of the OpenID specification, can be turned into a significant improvement (well, I think so), to the user experience and signals the way for a transparent single-sign-on experience across the web, using an OpenID provider of your choice. I look forward to the day when I login to my OpenID provider (actually, my browser does that automatically when I start it up), and from then on, I’m transparently logged in to the sites I use across the web, until I log out of my OpenID provider. One day, I’ll log in to my browser and be logged in to all the web services I use. One day, I’ll log out of my browser and be logged out of all the web services I use.