Update 15th November

It has been a busy few weeks lately culminating in a work trip to the USA last week. This trip was quite beneficial as, when one is stuck on a plane for 9 hours each way, or completely disconnected from the world 8300ft up the Colorado Rockies in a 1970s cabin with no phone signal, TV or Internet it allows for lots of thinking.

I’ve come up with a list of things that I want to achieve for Linkey by the end of Semester 1 (end of January ’13):

  • Complete the first draft of a case study looking at institutional uses of OAuth.
  • Invite our program manager, Chris Brown, for a site visit and spend the day looking over the case study and planning the last few months of the project.
  • Formally release the code I have been working on, including documentation, unit tests and tutorials.
  • Look at developing a .well-known standard for describing OAuth endpoints and enabling discovery (more on this in a future post).
  • Work with my colleagues in ICT to start implementing a joint OAuth and Microsoft UAG web single sign-on implementation.

I’ve been asked to work with the Orbital team to try and develop an authentication endpoint that will allow University of Lincoln staff and Siemens staff to securely sign-in to applications that have been developed by that project, but with each member of staff using their own institutional/company credentials.

OAuth 2.0 has been standardised

The IETF has approved the OAuth 2.0 Core and Bearer specifications and have now been published as RFC 6749 (Core) and RFC 6750 (Bearer).

Dick Hardt, one of the editors of the spec has summarised three important enhancements that OAuth 2.0 has over the old 1.0a spec:

  1. Simplicity: Client developers don’t need to do any cryptography or use a library to call OAuth 2.0 protected resources. The token can be passed in the HTTP headers or as a URL parameter. While HTTP headers are preferred, a URL parameter is simpler and allows API exploration with a browser.
  2. Token choice: implementers can use existing tokens that they already generate or consume. There are extension points so that the client can sign the token instead of it being a bearer token.
  3. Separation of roles: if the token is self-contained, then the resource can verify the token independently of the authorization server. Resources don’t have to call back to the authorization server to verify the token on each call, enabling higher performance and separation of security  contexts.

Update w/c 3rd September

I’ve spent the last few weeks working away on the OAuth PHP library which now includes a resource server as well as an authentication server. I’ve also started merging in Phil Sturgeon’s OAuth 2.0 client code library, which when I’ve finished, will result in a mean, lean PHP library for working with any aspect of OAuth 2.0 (authentication, resource sharing or client side). Both server classes are now fully unit tested and I’m at 90% code coverage for all of the methods. I’ve started writing documentation for the library too and I’m going to write a tutorial on how to build an OAuth secured API server in the CodeIgniter framework.

On the UAG side, both Tim and I have been reading Mastering Microsoft Forefront UAG 2010 Customisation (Amazon link). I’ve now got some ideas about how we can easily integrate the university’s OAuth server that I developed with our UAG install. More on this soon.