OAuth Case Study: A review into the uses of OAuth in higher education

The Linkey project has two main deliverables:

  1. Open source PHP libraries for OAuth2.0 clients and servers. Our code has been available for some time and is discussed in a previous post.
  2. A case study, which discusses the protocol and its uses.

Here is our case study.

Download the Case Study (PDF)

Read the Case Study online (Google Doc)

We welcome comments on the Case Study and invite you to leave them here on this blog post. Alternatively, you can contact us directly.

OAuth 2.0 PHP Library

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.

PHP, meet OAuth 2.0

Over the last few months I’ve been developing a PHP library that helps you work with OAuth 2.0 in a number of different ways:

  • Develop an authentication server which can be used as part of a web “single sign on” solution.
  • Secure your APIs with access tokens and scopes.
  • Easily sign users in to many different OAuth 2.0 identity providers.

The code for the authentication and resource server can be found on Github here https://github.com/lncd/OAuth2.

The server library code requires PHP 5.3+, is hooked into Packagist (a bit like Ruby Gems but for PHP) and has 100% unit test code coverage. It has built in support for the following grants:

You can easily create you own grants by extending \OAuth2\Grant\GrantInterface. I’m going to be creating plugins which support JSON web tokens and the SAML assertions.

The code for the client library can be found here https://github.com/lncd/OAuth2-Client – at the time of writing it isn’t quite finished, I’ll blog when it is.

Over the next few blog posts I’ll document how to use the libraries.

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.