Tag: specification

OAuth 2.0 PHP Library

Alex Bilbie / / Announcements, Code

Throughout the Linkey project I’ve been working on a number of PHP libraries that aim to make working with OAuth 2.0 easier.

The library is now at version 2.1, implements the entire core OAuth 2.0 specification and bearer token specification and has had over 1800 installations at the time of writing.

I’m very happy to announce that the University of Lincoln has agreed to transfer ownership of the code to the “PHP League of Extraordinary Packages” which means that it’ll continue to receive updates and be maintained by a number of developers around the world (myself included).

The server repository is now hosted at https://github.com/php-loep/oauth2-server and the client library is now hosted at https://github.com/php-loep/oauth2-client.

I have updated the wikis on both repositories with thorough documentation about how to use each library, and on the server library wiki I’ve added a lot more implementation about how to implement the library for common use cases.

My intention with all the code that has been written as an output of this project was that it would be as easy to use as possible and I’ve had some great feedback from developers:

— “Thanks for making your OAuth 2.0 server library public! It is people like you that make my job slightly more tolerable :)”

— “I wanted to thank you for your awesome library @alexbilbie :)”

— “Thank you for the great posts and lib”

— “If you drink, I will buy you a virtual beer!! What you built is awesome”

And finally in reply to a question that a developer asked me about how to do something with the library:

— “I’m really not surprised it was that simple – you’ve really built this with the end developer in mind. Once again, thanks very much for the info and the repo.”

To conclude I’m really happy with the code, I’ve learnt an awful lot as it has been developed and refined and I’m pleased that it’s new home will ensure long term sustainability.

OAuth 2.0 and the road to hell

Alex Bilbie / / Uncategorized

Eran Hammer who, until a few days ago, was the main editor of OAuth 2.0 has written this very damning blog post about the protocol

http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell/

I’ve been following the working group for about a year now and there has been an awful lot of bickering and mindless discussion.

As I’ve stated already, I’ve spent the last few weeks working on a brand new library that implements the current spec (draft 30) and I do feel myself agreeing with some of his points:

  • Yes the specification mess, I’ve highlighted and sticky noted the printed document to death and the flow between different sections is really bad
  • Some new features such as refresh tokens are overly complicated and don’t benefit the protocol, and it means clients now have to maintain access token state added to complexity
  • Just reading the spec you can tell how much it has been influenced enterprise – many features are very open ended so that you bolt OAuth onto something else (or something else onto OAuth)
  • Bearer tokens over SSL/TLS by themselves are bad and I think signatures need to come back
    • Basically if I steal someone’s access token I can use that wily nilly, however with signatures the entire request is signed with the client’s secret key so unless the secret key is leaked you can’t just use access tokens by themselves

I disagree however that the protocol (in it’s current state) is complicated, they’ve done great work at making it a 3 (or 4) legged protocol to just 2 legs and everyone agrees that bit of the protocol has been done well.

In terms of his suggestion that alternatives to OAuth that are outside the reach of the IETF might crop up I’m quite interested in this and if something crops up I’ll stick my nose in, and if one doesn’t then I’d be interested in having a go in writing one myself as an output of Linkey.

In terms of the extension documents (which include the assertions (SAML) extension, i don’t know enough about SAML to make any sort of informed opinion about this, however I’ve also still yet to see any public implementation of it.

Linkey, Chapter One

Alex Bilbie / / Nutshell

It’s 9am on Monday 25th June 2012 and the Linkey project is officially kicking off.

What is Linkey

Linkey is a JISC funded research project under the Access and Identity Management programme. It will run from June 2012 to May 2013.

The project will provide a detailed case study of the use of OAuth as an authorisation protocol here at the University of Lincoln. Working closely with the university Library, we will examine how the OAuth 2.0 specification can be integrated into a ‘single sign on’ environment alongside Microsoft’s Unified Access Gateway.

Our intention is to show how OAuth 2.0 can be used as part of an access and identity environment in higher education that improves the student experience by:

  1. A consistent and user centric sign-­in experience.
  2. A richer exchange of user information between applications.
  3. Easier development and implementation of new products.

Why?

A recent review of the university’s library systems and services indicated that we had around 10 core applications which provide access to over 150 other resources, all of which have different methods of authenticating users – some used LDAP to authenticate users (and so users use their network username and password) and others had their own database of users (which require a different passwords – and in some cases usernames – and every single one of these flows have a different sign in experience; some are web based with various designs, others are desktop based with a mixture of custom sign-in windows and Microsoft sign-in screens. Over 80% of user queries sent to the Library’s support email address around about problems accessing resources.

Outside of the library there are over 100 other systems and services that have visibility in the business processes across the university which also authenticate in a number of different ways.

All of these different authentication flows lead to a very inconsistent user experience and consistently for the last few years this has been highlighted in numerous student surveys.

Who?

I (Alex Bilbie) will be undertaking the majority of the work on the project. This will include researching technological solutions, engaging with end users, developing the open source OAuth 2.0 PHP server and working on the final implementation.

The principal user on the project will be Dave Masterson, Head of Electronic Library Services, who has been charged with improving the usability of our Library’s online services.

The project manager for the project will be Joss Winn, Senior Lecturer in CERD and co-ordinator of the LNCD group.

Tim Simmonds, Online Services Team Manager, will assume management and oversight of the technical implementation of both OAuth and UAG.

When?

The high level work plan is a below:

Month 1 2 3 4 5 6 7 8 9 10 11 12
Initiate project X
Community Engagement X X X X X X X X X X X X
Gather user requirements X X X X X X X X X X
Evaluate available technologies and options X X X X
Design Solution X X X
Technical development and implementation X X X X X X X
Write case study X X X X X X X X X X X
Write/submit conference paper X X X X X X
OAuth workshop  X
Project close X

You can follow the day to day activity on our Pivotal Tracker project page.

Outcomes

The anticipated outcomes of the project are:

  1. A case study of our implementation of OAuth 2.0 together with Microsoft’s UAG product. We will provide draft sections of the final case study in 12 monthly blog posts, allowing for early peer-review.
  2. Continued development of our open source OAuth 2.0 server (based on my server code), including an implementation of the SAML 2.0 Bearer Assertion Profiles for OAuth 2.0 specification and other relevant extensions to the main standard. We aim to produce a ‘drop in’ solution for OAuth 2.0, in a similar way that the SimpleSAMLphp project supports SAML implementations.
  3. A public workshop on the use of OAuth 2.0 in Further and Higher Education.
  4. A conference/journal paper, based on our case study.
  5. Expertise in the implementation of an institution-wide infrastructure for AIM.