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
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.
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.