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!