Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.
oAuth 1.0 and oAuth 2.0
Has anybody had a need to implement these rather than basic authorisation and if so any tips on how to do so?
Don, perhaps some alternative authorisation framework is in the pipeline? Post conference I understand but maybe?
The basic framework works well but just thinking possibilities moving forward.
Don, perhaps some alternative authorisation framework is in the pipeline? Post conference I understand but maybe?
The basic framework works well but just thinking possibilities moving forward.
Comments
We've implemented a solution for OI to act as a client that connects to another web service via OAuth, but we have not had a requirement to implement OAuth as an authentication protocol within the framework. If you needed to do something along these lines, then updating HTTP_Authentication_Services is the proper routine to use (as I'm sure you already guessed).
There are no plans in the pipeline for us to do this. To be honest, I don't think this will ever happen unless we are contracted to implement it. OAuth, in my opinion, is not ideal for business-class authentication. It only nominally authenticates and provides no authorization. It puts the responsibility of authentication into a third-party's hands and it is not a stateless as HTTP and REST want to be.
I may have responded a bit stridently, so I want to revisit this topic. My reservations against OAuth come from two concerns. First, while OAuth is quite popular and is becoming the de-facto authentication protocol by just about everybody, it has known vulnerabilities. Even some of the original contributors to the OAuth standards have walked away from the project due to these issues. Second, most people like OAuth (and OpenID, which lays on top of OAuth 2) because of the convenience of using third-party (aka Relying Parties) to provide authentication of credentials (e.g., I get to use my Google account to log into everything). I've always found the notion of a provider of critical business assets allowing some other company the responsibility of granting this kind of access rather odd. Hence, for the type of apps that we (i.e., the OpenInsight community) are likely to build, I would think that the business client would want that responsibility.
Having said that, I never really considered that a business might want to use OAuth and providing the authorization server. Essentially this is what HTTP Basic Authentication requires. Hence, my second concern cited above can be eliminated under these conditions. With that in mind, I revisited the PayPal REST API documentation and read through how they implement OAuth 2 for developers:
How PayPal uses OAuth 2.0
I think they explain rather well the framework for handling OAuth 2 internally (although they don't actually get into the specifics of OAuth 2 itself). What is nice about their implementation is that the OAuth 2 token is still passed along in the HTTP Request Authorization header, just as we are doing with HTTP Basic Authentication. This will make it super easy for you to extend HTTP_AUTHENTICATION_SERVICES to extract the token. Then all you need to do is validate the token based on the implementation of OAuth within your system.
I hope this gives you some traction.
My position on OAuth as a primary means of authentication has not changed. However, I now better understand that OAuth can be quite useful as a way of augmenting a web application's functionality by allowing it to perform tasks or access resources that belong to the user.
Supporting OAuth is relatively easy. However, since OAuth is a framework rather than a standard, each implementation of OAuth will vary slightly. Therefore there is no way to build generic support for OAuth in the SRP HTTP Framework product in the same way we could do so for HTTP Basic Authentiation. Also, due to the way OAuth uses URL callbacks, the HTTP_Authentication_Services routine is not used at all. It needs to be by-passed, which is why we now allow you to enter non-authenticated URLs in the setup record.
I intend to write a blog post in the near future that details how we implemented OAuth. This should help others figure out how to do this for themselves with virtually any provider that uses OAuth.
I did notice this unlikely occurrence.
When I originally asked the question it was prompted by the thought this may become a requirement in the future considering it rather than an immediate need.
Whilst it still isn't an immediate need, the thought has not gone away so I look forward to the blog. I'm always more comfortable knowing someone somewhere has done it before.