OAuth 2.0
Protocol :
Traditionally all public web apps
have had their own authentication mechanisms, typically implemented with
application specific username-password pairs. With this approach, the users had
to share their credentials over several services which is not secure and very
intrusive.
To overcome this issue , OAuth
protocol has been proposed . OAuth 2.0 is a protocol that allows distinct
parties to share information and resources in a secure and reliable manner.
Using OAuth 3rd party applications no longer need to access user’s
password. The idea behind OAuth is simple: Provide a standard way for
accessing to protected resources, without the need of sharing passwords.
Using OAuth mechanism user can
login to third party websites using social media accounts like facebook,
twitter, google, without exposing their passwords. This is been shown in the
login screen below:
Terminology :
In order to understand OAuth 2.0,
it’s important to first understand the relevant terminology. Below are the key
terms.
1. Authentication
Authentication is the process of
verifying the identity of a user—knowing that the user is who they claim to be.
In the real world, when a police
officer asks for one’s identification, Officer is verifying one’s identity by
ensuring that the picture on your identification matches your likeness.
1.1 Federated Authentication
Although many applications have their own system of accounts (including
usernames and passwords), some applications rely on other services to verify
the identity of users. This
is called federated authentication.
In
a corporate IT environment, applications may trust an Active Directory server,
a LDAP server, or a SAML provider to authenticate users.
On
the Web, applications often trust OpenID providers (such as Google or Yahoo!)
to handle the authentication of users. There are many benefits to federation
for both application
developers and users. OpenID is the most common open web protocol for handling
federated authentication.
2. Authorization
Authorization is the process of
verifying that a user has the right to perform some action, such as reading a
document or accessing an email account. This typically first requires valid
identification of the user (authentication) in order to check whether the
actual user is authorized.
When a police officer pulls over
one’s car for speeding, officer first authenticates you using your driver’s
license (to verify your identity) and then checks the license (expiration date,
restrictions, etc.) to ensure you’re authorized to drive.
2.1 Delegated Authorization
Delegated authorization is granting access to another person or application to
perform actions on your behalf.
When one drives your car to a classy hotel, they may offer valet parking. You
then authorize the valet attendant to drive your car by handing him the key in
order to let him perform actions on your behalf.
OAuth works similarly—a user grants access to an application to perform actions
on the user’s behalf and the application can only perform the authorized
actions.
3. Roles
There are several key actors in
the OAuth protocol flows:
Resource server
The server hosting user-owned
resources that are protected by OAuth. This is typically an API provider that
holds and protects data such as photos, videos, calendars, or contacts.
Resource owner
Typically the user of an
application, the resource owner has the ability to grant access to their own
data hosted on the resource server.
Client
An application making API
requests to perform actions on protected resources on behalf of the resource
owner and with its authorization.
Authorization server
The authorization server gets
consent from the resource owner and issues access tokens to clients for
accessing protected resources hosted by a resource server. Smaller API providers may use the same application and URL space for both the authorization
server and resource server.
Why Is Registration Necessary? :
Registration enables the
application developer to obtain client credentials, which are used to
authenticate requests made to the authorization server. These credentials are
critical in protecting the authenticity of requests when performing operations
such as exchanging authorization codes for access tokens and refreshing access
tokens.
Registration also gives the API
provider information to improve the user experience during the authorization
process. When presenting an application’s request for data access to the user,
the API provider will often display the name and logo of the application.
Example below shows how Google uses the registration information on the approval screen.
Tools and Libraries :
Although OAuth 2.0 is relatively young, there are still a variety of tools and libraries available for developers to make using it easier.
Google’s OAuth 2.0 Playground
Google has built a new version of
its OAuth Playground tool for OAuth 2.0 (Figure below ). The OAuth 2.0
Playground demonstrates the three-step process for a typical server-side web
application Authorization Code flow: getting an authorization code, exchanging
it for an access token, and making API requests. It also supports the Implicit
flow for client-side web applications.
While the default configuration
is to use Google’s APIs and OAuth endpoints, the tool does enable you to
specify a custom client ID, client secret, and custom endpoints. Salesforce has
blogged about how to use the tool with their APIs.
Libraries :
Many major API providers build
and maintain client libraries for accessing their specific services. Some of
these libraries, such as the Google API Clients and Facebook SDKs provide
built-in support for OAuth 2.
Here are some API-specific client
libraries which implement OAuth 2.0:
• Google APIs Client Libraries
for Java, Objective-C, PHP, Python, Ruby, JavaScript
• Facebook SDKs for JavaScript,
Android, iOS, PHP
• Foursquare does not provide
official libraries, but it links to many community-contributed libraries, many
of which support OAuth 2.0
References :
Mastering OAuth 2.0by Charles
Bihis
Getting Started with OAuth 2.0by
Ryan Boyd
Comments
Post a Comment