About OAuth Use for API Authorization

OAuth is an API-based authorization protocol that allows a third-party website or application to authorize access to a user’s data without the need for users to share their login credentials. It works its magic though the use of tokens.

Let’s look at the use of OAuth for authorization as opposed to authentication, which is another use of the same protocol.

The Overall Process for Authorization

OAuth serves as a way for users to log into third-party websites by using their Microsoft, Google, Facebook or Twitter accounts — and without exposing their passwords to the third party. These sites authenticate the user to the requesting website.

To start the process, the website being queried establishes an OAuth interface and a secret key for the website doing the requesting. This creates a session to validate the requester.

Once the user requests access to the data or resources of the client website, he or she is forwarded to the login procedure of the primary website to provide credentials. Upon successful authentication, an authorization token is sent from that primary website to the requester as an acknowledgment. That allows the access or other resources originally requested.

How Google Does It

To enumerate the steps in the authorization process, consider the way Google implements it. The first step in its system is to get OAuth 2.0 credentials from the Google Developer Console. These may include a client ID and client secret that are known to both Google and an application. The set of values varies based on what type of application is being built. For example, a JavaScript application does not require a secret, but a Web server application does.

The Google Authorization server next generates an access token. As OpenStack explained, a single access token can grant varying degrees of access to multiple APIs. The value of the scope parameter in the request will control the resources and operations that an access token permits. It is generally recommended that only permissions needed for the specific action taken at one time be granted rather than front-loading a request with all possible permissions.

After an application obtains an access token, it sends the token to a Google API in an HTTP authorization header. This is good practice compared to the use of URI query-string parameters, which have a higher possibility of being detected.

Now, access tokens have a lifetime. If the application needs access to some Google API beyond the lifetime of a single access token, it can obtain a refresh token at the same time, which will allow for new access tokens in the future.

API Authentication

Several buttons (one for each of the supported services) will appear on the third-party site to initiate the process, but it is important to make sure these processes are secure. For example, Google’s OpenID Connect protocol is a layer on top of OAuth and is routinely used for authentication. Google even provides libraries to support these methods, though they exist mostly to prevent coder mishaps.

“Given the security implications of getting the implementation correct, we strongly encourage you to take advantage of a prewritten library or service,” Google stated. “Authenticating users properly is important to their and your safety and security, and using well-debugged code written by others is generally a best practice.”

The authentication process includes a screen describing the information that the user releases and the terms that apply. When the user logs into the service via authorization, he or she may be asked to give consent for the app to access to their email address and basic account information. Once authorized, tokens for use in other available service APIs may be provided.

Don’t Reinvent the Wheel

In many ways, OAuth can get complex to implement — hence the prewritten libraries available for differing code frameworks. But the end result gives capabilities to Web-based services and apps that would not otherwise be possible.

The wheel does not need to be reinvented for each specific access situation. If another service has done a good job of it, and is willing to share their work with the right kind of request, then tools such as OAuth should become more widespread.

Share this Article:
Larry Loeb

Principal, PBC Enterprises

Larry Loeb has written for many of the last century's major "dead tree" computer magazines, having been, among other things, a consulting editor for BYTE magazine and senior editor for the launch of WebWeek. He wrote for IBM's DeveloperWorks site for seven years and has written a book on the Secure Electronic Transaction Internet protocol. His latest book has the commercially obligatory title of Hack Proofing XML. He's been online since uucp "bang" addressing (where the world existed relative to !decvax), serving as editor of the Macintosh Exchange on BIX and the VARBusiness Exchange.