Project dissemination at the Internet Identity Workshop

Last week I was in San Francisco for the 16th Internet Identity Workshop to disseminate the Linkey project and engage with those in the online identity communities.

The event was sponsored by many big names including Microsoft, Ping Identity, Google, Janrain, Yubico, Cisco, OneID and NetIQ. In attendance were employees from all of the sponsor companies as well as delegates ranging from freelance developers to information compliance officers at big companies to authors of many Internet specifications and protocols such as OpenID, OAuth and SAML. About half of hundred or so delegates had travelled from outside North America including about ten of us from Europe. Surprisingly I was the only delegate representing an educational institution.

The conference itself was un-conference style – i.e. each morning delegates would volunteer sessions which were then slotted into the timetable. A full list of all of the sessions can be found here. The sessions people put forward tended to either be very technical or were higher level, almost philosophical discussions.

Here is a list of sessions I attended (session notes can be found here):

  • T1G: Native Apps – SSO
  • T2B: Strong 2-Factor For All – Google and FIDO Alliance
  • T3C: The OAuth Complicit Flow
  • T4G: Identity Federation: Failed Consumer Experiences and WHat We Can Do About It
  • W1H: OAUTH Client Registration
  • W3B: OAuth 2 Bootstrapping from device to browser (technical)
  • W4B: Google’s Auth goals for the next 5 years
  • Google are strongly committed to OAuth!!!!
  • W5I: OAuth 2 Federation – RS trust external AS
  • TH2E: Practical DATA PROTECTION – Avoidance? EU and US ?
  • TH3A: RESPECT CONNECT “Facebook Connect for Personal Clouds” OR “Social Login that Doesn’t Suck”
  • TH4F: Self-Hosted Personal Clouds (FreedomBox and Raspberry PI)

The two main overarching topics throughout the event were “privacy” and “data ownership”. There were also a number of sessions about security, with one session that I attended by Google about 2-factor authentication resulting in quite heated discussion (namely because the work Google and the FIDO Alliance is not public and there is a high fee for membership).

Another interesting session was called “The OAuth Complicit Flow” (notes here) which had the premise of “what if the an OAuth authorisation server asked you to agree to “allow this application to connect to your account and murder someone” and there was no deny button. The discussion dealt with the issue of some applications asking for too many permissions, users not reading through the approve screens (similar to how users just accept EULA agreements) and applications refusing to let users access them unless they agree to allowing the application share stuff on their Facebook wall, or see the user’s friend list. Potential solutions that came out of this discussion was “reactive” permission requests as opposed to “preemptive” permissions – similar to how some iOS apps don’t ask for permission to send push notifications unless you click a button in the settings for that app.

I got the opportunity to have a chat with Mike Jones from Microsoft who has been leading much of the work on the OAuth 2.0 and OpenID Connect specifications. He answered a few questions I had about edge cases in implementations and he was interested in the PHP libraries I’d developed as part of the project.

I didn’t have the opportunity to talk at length about Linkey but in all the sessions I attended I tried to take part and I had some really interesting discussions with people about some of work that we’re doing in HE around open data and open APIs (including work on OAuth) and I was able to talk about some of the issues we faced with implementing OAuth in enterprise environments (because of incompatibility and lack of understanding compared to SAML).

I feel that the conference was definitely worth attending and I would encourage JISC and other interested parties in the education sectors to try and attend the next Internet Identity Workshop as I left feeling that we’re dealing with some very similar problems that even the very large organisations present such as Oracle are dealing with.

Twitter’s official clients have their OAuth keys leak

Someone has posted a Github Gist with all of the client identifiers and secret keys for the official Twitter clients on various platforms.

This just highlights why it is imperitive that you don’t screw up like Facebook did by allowing wildcard client redirect URIs.

The client redirect URIs must be absolute and stored on the authorisation server.

So what can Twitter do about this?

They could release new binarys for all of their clients with new keys and invalidate the old keys, but clients that haven’t been updated will suddenly stop working and leave users confused and frustrated. Also it will be trivial for the new keys to be leaked too.

Alternatively they could come up with some sort of mechanism to allow the official clients to download new keys on the fly but then these could be captured with a man-in-the-middle attack.

But is it actually a problem?

First, it is important to recognise that this is really only a problem for desktop/mobile app clients (assuming that is that web server based clients themselves keep their keys secure – the differnece being that someone would have to break into a web server to get to them).

Therefore as long as Twitter aren’t giving their own applications additional functionality that 3rd party clients can’t replicate then there isn’t too much of a problem because with this equal playing field scenario it could be Tweetbot or MetroTwit we’re talking about.

Having said that, the official iOS mobile client at least does allow you to register a new account, so these leaked keys could be used to create spam accounts.

With 3rd party Twitter clients being limited to 100,000 access tokens this could tempt some to make use of these keys however if they were caught then they risk being named and shamed by the media and that in turn could also result in developer accounts being banned by Apple and Google from their app stores.

Is OAuth to blame?

No, the OAuth protocol is behaving as it designed to here. That is, if a 3rd party client presented a correctly formed request with these valid keys and the correct redirect URI then, assuming Twitter doesn’t have some extra security in place to validate requests using their keys (such as validating user-agent strings for example), the authorisation server will assume the request is genuine.

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.

Linkey update w/c 18/02/2013

It’s been a long time since I last gave an update on Linkey so I’ll try to summarise what has happening recently.

In late Janaury, Chris Brown the manager for the Access and Identity Management (AIM) programme visited us here in Lincoln. We spent a few hours looking over the case study that I’ve been working on and Joss and I discussed how the work we’re doing on Linkey fits into the eco-system that LNCD have developed. A number of actions came out of the meeting:

  1. Get in touch with a number of contacts that Chris has at Kent and Newcastle to discuss a number of AIM related projects and what we can learn from them.
  2. Get in touch with contacts at Warwick University who have a number of APIs and tools that are secured with OAuth 1.0. If possible I would like to include their work in the case study.
  3. Speak to JISC InfoNet to see if a toolkit could be created out of the case study.

I’ve spent a few months trying to find an appropriate conference to go to so that I can engage with the AIM community and discuss the project and it’s outputs. After much searching for the right conference I’m happy to say that I’m going to be going to the 16th Internet Identity Workshop in Mountain View, California. Being in the heart of Silicon Valley I’m really looking forward to meeting developers and evangelists from companies such as Google, Facebook and Microsoft, all of whom are trying to be “our” online identity provider.

As part of my research for the case study I have been looking into the many use-cases of OAuth. Recently I’ve been experimenting with securing an RDF SPARQL server to only respond with triples that an access token (sent in a HTTP header) can access. I will blog about this later once I’ve got a bit further with it.

Since January I’ve been working on the OAuth code which has had some great contributions from some guys from the US. It is now finished and running in production in several places (more on this in another blog post). In addition, now that the code is complete I can start developing a plugin for the SAML bearer grant.

Finally, the Linkey project will officially finish on the 25th June.

Update 26th November

Last week, after finally getting access to one of the new UAG servers I’ve begun working through Microsoft forefront UAG 2010 Administrator’s Handbook which details how to configure the software and hook different applications up to it. I’m not quite in a position to write anything more detailed than this at the moment but hopefully later in the week there will be more to say.

Open Athens LA is being installed by ICT. This will improve the flow of metadata between the university and services. It will also reduce the number of authentication screens for users.

Last week I started writing the case study about institutional uses of OAuth. I’ve written about 1800 words so far and I anticipate writing in the region of 5000-6000 words. I’m intending to have a first draft finished by the end of January when Chris Brown the programme manager for JISC AIM will be visiting us for the day to look over it and help us plan the last few months of the project.

This week I’m going to review Hawk, which is a new HTTP authentication standard by Eran Hammer. It is basis of another standard, Oz which Eran is proposing as an alternative to OAuth.