March 3, 2016 By Larry Loeb 3 min read

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.

More from Identity & Access

Passwords, passkeys and familiarity bias

5 min read - As passkey (passwordless authentication) adoption proceeds, misconceptions abound. There appears to be a widespread impression that passkeys may be more convenient and less secure than passwords. The reality is that they are both more secure and more convenient — possibly a first in cybersecurity.Most of us could be forgiven for not realizing passwordless authentication is more secure than passwords. Thinking back to the first couple of use cases I was exposed to — a phone operating system (OS) and a…

Obtaining security clearance: Hurdles and requirements

3 min read - As security moves closer to the top of the operational priority list for private and public organizations, needing to obtain a security clearance for jobs is more commonplace. Security clearance is a prerequisite for a wide range of roles, especially those related to national security and defense.Obtaining that clearance, however, is far from simple. The process often involves scrutinizing one’s background, financial history and even personal character. Let’s briefly explore some of the hurdles, expectations and requirements of obtaining a…

From federation to fabric: IAM’s evolution

15 min read - In the modern day, we’ve come to expect that our various applications can share our identity information with one another. Most of our core systems federate seamlessly and bi-directionally. This means that you can quite easily register and log in to a given service with the user account from another service or even invert that process (technically possible, not always advisable). But what is the next step in our evolution towards greater interoperability between our applications, services and systems?Identity and…

Topic updates

Get email updates and stay ahead of the latest threats to the security landscape, thought leadership and research.
Subscribe today