The Tesco.com API will be adopting the 'OAuth Core 1.0 Revision A' standard for third-party web access to customer accounts using the Tesco.com Grocery API Beta Edition from Phase 2 onwards.
OAuth, short for 'Open Authorization', is an open protocol to allow secure API authorisation in a simple and standard method from desktop and web applications.
Why is this good? Quite simply, customers will not have to give third party web sites their Tesco.com grocery login email address and password in order for that web site to have access to that customer's product range and basket. Instead, customers will give permission using a 'key' linked to their account. The key can be withdrawn at any time without the customer having to reset their password.
From the OAuth web site (http://www.oauth.com):
"The OAuth protocol enables websites or applications (Consumers) to access Protected Resources from a web service (Service Provider) via an API, without requiring Users to disclose their Service Provider credentials to the Consumers. More generally, OAuth creates a freely-implementable and generic methodology for API authentication.".
OAuth will be built into phase 2 of the forthcoming beta version of the Tesco.com API over the coming months. Until then, third party web sites wishing to use the forthcoming beta Tesco.com API (due for release at the end of August) can continue to use the current authorisation method of requesting username and password.
We will need to make sure that using OAuth is as painless for the customer as possible but there are several very good implementations out there so I'm confident that we can find the right balance between security and ease of use.
Third party web sites should keep in touch with the Tesco API Innovation Forum at http://www.techfortesco.com/forum for more information about switching over to the OAuth mechanism.
We will make sure that the implementation will require only a tiny change to third party web applications principally around use of the 'Login()' method (in the AccountClient class). Applications that call Login() get returned an instance of the Session class that is used as a token when calling all the other methods in the API for that customer. We'll make sure this behaves as it does today so you don't have to re-code your application beyond using Login() itself.
Client applications that are built for consumer devices can continue to use the current authorisation mechanism without having to make any changes to their applications and will not need to use OAuth (unless they wish to). This is because these apps will talk directly with the Tesco API and don't go via a third-party server.
We do reserve the right to provide new authorisation mechanisms and deprecate old methods as technology moves forward, but 'old and new' mechanisms will sit side-by-side for a while to give reasonable time for developers to update their sites to adopt the new service.
And if you didn't understand a word of this blog entry, relax;
I'll return to my usual higher-level writing shortly!
Monday 17 August 2009
6 comments:
As this blog grows in readership - and because it carries the Tesco brand - I have had to become more careful about the sort of comments that are acceptable. The good news is that I'm a champion of free speech so please be as praising or as critical as you wish! The only comments I DON'T allow through are:
1. Comments which criticise an individual other than myself, or are critical of an organisation other than Tesco. This is simply because they cannot defend themselves so is unfair and possibly libellous. Comments about some aspect of Tesco being better/worse than another equivalent organisation are allowed as long as you start by saying "in my personal opinion.." or "I think that...". ... followed by a "...because.." and some reasoned argument.
2. Comments which are totally unrelated to the context of the original article. If I have written about a mobile app and you start complaining about the price of potatoes then your comment isn't going stay for long!
3. Advertising / web links / spam.
4. Insulting / obscene messages.
Ok, rules done - now it's your go:
Subscribe to:
Post Comments (Atom)
Thats great stuff Nick thanks for listening to all the feedback, it will make our life much easier using this than having to try and convince our users why they should give us their tesco.com password.
ReplyDeleteBTW as far as I'm concerned I don't mind if you do break the API interface during the beta stages if it leads to a better API.
This is excellent news. I feel safer as a developer and a shopper.
ReplyDeleteSome people consider mobile apps to be intrinsically trusted, not needing OAuth - what are your thoughts on this?
Hey Nick - did you guys look into OpenID as well as OAuth? It would be interesting to understand the analysis that lead to the selection of OAuth.
ReplyDeleteNick:
ReplyDeleteYou won't be disappointed with the protocol. We went through a few months of research on how we should approach authentication for our API(http://developer.fellowshipone.com) and all paths pointed to OAuth.
By far, the community and the authors of the protocol have been more than supportive and we have found that it even supports multi-tenant, multi-user with multi-persona user models (with some extension)
So far all of our consumers have had very little difficulty with consumption, and they are using several different platforms (iPhone, PHP, Rails, .NET, etc...)
Great choice!
Don't know how I missed this one. Great news.
ReplyDeleteHello Nick: Is OAuth available for current Tesco API? I couldn't find any information regarding its current status.
ReplyDelete