OAuth was chosen because it offers a more secure authentication option than the method already in place, noted Google software engineer Ankur Jain in a blog posting. Until now, administrators had to sign calls to Google Apps APIs (application programming interfaces) with their username and password, which is a security risk.
With OAuth, Google Apps can provide third-party applications with tokens that can be used to access the APIs of different Google apps, eliminating the need to supply log-in names and passwords for each API call. The APIs for Google Apps provisioning, e-mail migration, administration settings, calendar resources, e-mail settings and audit all now can interact with the OAuth signing mechanism.
Consumer-facing Web services started using the protocol as well. Twitter made OAuth mandatory for third-party apps earlier this month and Facebook has started using version 2 of the protocol.
Google had been looking for some time for a simpler way for outside Web application developers to secure their API calls, noted Eric Sachs, a product manager for the Google security team, in an interview earlier this year about version 2.0 of OAuth. Traditional Web services security models such as SAML (Security Assertion Markup Language) and WS-Security proved to be too complex for those not well-versed in security. OAuth tokens work a bit like browser cookies, but for APIs, he said.
“That level of simplicity enables a lot of applications that might not have APIs to offer APIs,” he said.