May 16, 2017
Suraj Kumar, Software Engineer, Azuga.
This article provides the overview of Oauth 2.0 protocol. It discusses the different actors and steps involved in the process of Oauth 2.0 implementation.
OAuth stands for Open Authorization. It’s a free and open protocol, built on IETF standards and licenses from the Open Web Foundation. It allows users to share their private resources with a third party while keeping their own credential secret. These resources could be photos, videos, contact lists, location and billing capability, and so on, and are usually stored with another service provider. OAuth does this by granting requesting (client) applications a token, once access is approved by the user. Each token grants limited access to a specific resource for a specific period.
OAuth2 supports “delegated authentication” i.e. granting access to another person or application to perform actions on your behalf. consider this scenario: you drive 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.
OAuth2 works similarly—a user grants access to an application to perform limited actions on the user’s behalf and access can be revoked when it become suspicious.
Resource server: the server hosting user-owned resources that are protected by OAuth2. Resource server validates the access-token and serves the protected resources.
Resource owner: typically user of the application is the resource owner. Resource owner has the ability to grant or deny access to their own data hosted on the resource server.
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.
Client: an application making API requests to perform actions on protected resources on behalf of the resource owner. Before it may do so, it must be authorized by the Resource Owner, and the authorization must be validated by resource server/authorization server.
OAuth2 defines two client types, based on their ability to authenticate securely with the authorization server (i.e., ability to maintain the confidentiality of their client credentials):
1) Confidential: clients capable of maintaining the confidentiality of their credentials. Confidential clients are implemented on a secure server with restricted access to the client credentials (e.g., a web application running on a web server).
2) Public: clients incapable of maintaining the confidentiality of their credentials (e.g. an installed native application or a web browser-based application), and incapable of secure client authentication via any other means.
Consider a scenario, you are developing a facebook fun app call it “FunApp”. FunApp needs access to user’s public profile, photos, posts, friends etc. Now the problem is: How can FunApp get the user’s permission to access his/her data from facebook, simultaneously facebook should be informed that user has granted the permission to the FunApp so that facebook will share the user’s data with this app.
User share his/her facebookcredential(username, password) with FunApp. This approach has some challenges i.e. Trust, Unrestricted access, what if user changes the facebook password? etc.
Funapp would redirect users to an authorization page of the Facebook if the app needed access to user data. Users would log in to their accounts and grant access, and then the FunApp would get a access token from Facebook to access the user’s’ data. while Oauth2 has solved these challenges, it also created costs for developers. Developers need to learn and implements OAuth2 framework for their APIs.
OAuth requires that client register with the authorization server. Authorization server ask some basic information about client such as name,redirect_uri( url where authorization server will redirect when resource owner grant the permission) and returns client credentials(Client-id, Client-secret) to the client. 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. for example:
Facebook requires you to register your client on the Facebook Developers portal. Go to Facebook developers portal and register FunApp and get client credentials.
FunApp needs to get access token from Facebook to access the user’s data. In order to get Access Token FunApp redirects the user to the facebook’s login page. On successful login Facebook redirects on the redirect_uri(as registered in step 4) along with the short-lived authorization code. FunApp exchange the authorization code to get the long-lived access token. access token is used to access the user’s data. This is the most popular flow in Oauth2 called Authorization code grant. here is the sequence diagram to get Access token in Authorization code grant:
To get the access token, client obtains authorization from the resource owner. The authorization is expressed in the form of an authorization grant, which the client uses to request the access token. OAuth2 defines four standard grant types: authorization code, implicit, resource owner password credentials, and client credentials. It also provides an extension mechanism for defining additional grant types.
This grant type is optimized for confidential clients (web application server). The Authorization Code flow does not expose the access token to the resource owner’s browser. Instead, authorization is accomplished using an intermediary “authorization code” that is passed through the browser. This code must be exchanged for an access token before calls can be made to protected APIs.
This grant type is suitable for public clients. The Implicit Grant flow does not accommodate refresh tokens. If the Authorization server expires access tokens regularly, your application will need to run through the authorization flow whenever it needs access. In this flow, an access token is immediately returned to the client after a user grants the requested authorization. An intermediate authorization code is not required as it is in the Authorization code grant.
The resource owner password credentials grant type is suitable in cases where the resource owner has a trust relationship with the client, and resource owner agrees to share hise/her credential(username, password) with client. Then client use resources owners credentials to get the access token from Authorization server.
This grant type is suitable when client itself owns the data and does not need delegated access from a resource owner,or delegated access has already been granted to the application outside of a typical OAuth flow. In this flow user consent is not involved. Client exchanges his client credentials to get access token.
Making API calls using the OAuth 2.0 access token may encounter errors if the access token is no longer valid because the token expired or was revoked. In this case resource server will return 4xx error code. Client can get the new access token using the refresh token (refresh token was obtained when authorization code was exchanged for an access token).
Oauth 2.0 is becoming popular solution for protecting APIs. This is an attempt to provide an overview of the OAuth 2.0 process, as well as provide a way to obtain an access token. I hope it has been helpful.
Have fun Integrating Apps!