Last year, Semantico was approached by Geoff Bilder of Crossref fame, to assist in building the ORCID (Open Researcher and Contributor ID) system. For ORCID to succeed it needed an authentication method that enabled third parties to interact with the system. Geoff was instrumental in investigating the use of OAuth 2.0, and asked us to provide recommendations on the best way forward. After our investigations, we felt that OAuth 2.0 was the right choice.
We have been implementing OAuth 2.0 as a provider to secure the ORCID front-end website and APIs to ensure we have a standardised, distributed system with a view to maximising take-up from third-parties to interact with the system. For us OAuth 2.0 meets all of those needs with an intuitive, well-thought out set of requirements. And some of that is thanks to Eran Hammer.
If you haven’t already guessed what has prompted this post, it’s the news that Eran Hammer has very publicly resigned from the OAuth working group, asking for his name to be removed from the specification.
If you read past the evident anger, Eran does point out that the framework, in the right hands, is a great success. I don’t have the figures to hand, but Facebook alone must authenticate and authorise millions of users every day using OAuth 2.0. Not to mention, Google, SalesForce etc. etc. And if you’re thinking that these companies have enough resources to make anything a success, you’d be right, they could. So, that can only be another feather in the cap for OAuth 2.0, as if they hadn’t had a great deal of confidence in it, they wouldn’t have invested in it.
When researching how to implement OAuth 2.0 at the beginning of the ORCID project, we investigated a few possible avenues. We’re predominantly a Java house, and more specifically use Spring for our IoC and web layers, so it didn’t take long for us to discover Spring Security’s OAuth project. Initially created by Ryan Heaton, OAuth for Spring Security has been taken under the wing of Spring and has enjoyed active development under the watchful eye of Dave Syer.
We’re in the fortunate position that our security needs are well defined and don’t venture away from the tried-and-tested scenarios we’re so familiar with Facebook and Google, etc. Opting for an existing implementation has given us peace of mind for many reasons, but not least because we were aware that OAuth 2.0 has been a bit of a moving target and we needed something that was actively being developed and moved forward. Being open source, its given us a well tested product utilising a great standard.
Like any framework – particularly where security is concerned – OAuth 2.0 has its complexities. It leaves some areas to be interpreted with a bit of common-sense. But lets not get over excited, software developers aren’t stupid. If there are areas that need more explanation and definition, there are plenty of examples of their implementation from the big boys!
As we’ve found with the ORCID project, it is not difficult to implement OAuth 2.0 properly. We are confident it is the right choice.