An overview of OAuth 2.0
OAuth 2.0 is an authorization framework used by applications to provide client applications with secure delegated access. It works over HTTPS and authorizes devices, APIs, servers, and applications with access tokens rather than credentials. It enables apps to obtain limited access (scopes) to a user’s data without giving away the user’s password.
Problems with traditional client-server authentication model
The traditional client-server authentication model comprises of a mechanism where a client (user) gets access to a protected resource on the server by using it’s credentials like username and password. If the client (user) wants any third-party application to access it’s resource that is present on the server, then it has to share it’s credentials with that third-party application, which can create a lot of problems like -
- The third-party application will get full access of the user’s resource and it can misuse it.
- It can change the password, which will make the resources inaccessible to the user, who is the actual owner of the resource.
- If the third-party application doesn’t employ any of the two bad practices mentioned above. But, if the security of that application is compromised in any way, then the user’s credentials shared with that application will also get compromised. As a result, the user’s resource won’t be secured anymore.
The invention of OAuth addresses these issues. To grant a third-party application to access the user’s resource stored in a resource server, user is not required to share his credentials. Instead, the third-party application will be given an access token by the authorization server with specific scope, lifetime, and other access attributes. This token will be used by that application to access user’s resources that it is authorized to.
OAuth is designed for use with HTTP . It cannot be used with any other protocol.
- Resource — It is the thing which is protected and needs to be accessed.
- Resource owner — It is the person who has access to the complete resource. He is also capable of granting access to other entity to access his resource.
- Resource server — It is the server that is hosting the protected resource of the resource owner.
- Client — It is an application that is trying to access the protected resource on behalf of the resource owner with his authorization.
- Authorization server — This server is coupled with the resource server, which is responsible for making sure whoever is accessing the resource server is authorized. It also issues access tokens to the client.
- Scope — It sets the limit of an application’s access to a user’s account. An application (client) can request one or more scopes and this information is then presented to the user in the consent screen. When the user gives his consent, the access token is issued to the application and it will be limited to the scopes granted.
- Authorization grant — It is a credential that represents the resource owner’s authorization which will be used by the client to obtain the access token.
- Access token — It defines the scopes and durations of access granted by the resource owner, which is enforced by the resource and authentication servers. In a nutshell, it is a credential which is used to access protected resource of the owner.
- Refresh token — This is the credentials which is used to obtain new access token when the existing one expires. Issuing a refresh token is optional and totally up to the authorization server. In case, the authorization server issues refresh tokens, then it is included with the access token.
There are four roles defined by OAuth viz. Resource owner, Resource server, Client and Authorization server.
Now, let’s understand two important concepts — Front Channel Flow and Back Channel Flow.
In Front Channel Flow, the resource owner starts the flow by asking the client application on the browser to access his protected resource. The client then sends authorization request with the scopes via browser redirect to the Authorize Endpoint on the Authorization Server. Then, authorization Server returns a consent dialog box, where the resource owner has to give his consent. If the consent is given, the Authorization grant with the Authorization code is passed back to the application via browser redirect.
Since, all the mentioned processes are happening in the browser only, that’s why it is not very much secure. The credentials of Authorization grant can be intercepted by any malicious entity. If the client is given access to the protected resource with that Authorization code only, then the security of the owner’s resource will be compromised.
To solve this problem, Back Channel Flow comes into picture. The Client application sends an access token request to the token endpoint on the Authorization Server with confidential client credentials and client ID. This process exchanges an Authorization Code Grant for an Access Token and a Refresh Token (which is optional). This process is called back channel flow because here the communication of the client application with the authorization server is private and not through the browser.
When the client gets the access token, it can access the protected resource of the owner.
The above diagram shows a type of OAuth flow, which is called as Authorization code flow and it is the most secure OAuth flow.
Other OAuth flow types are Implicit Flow, Client Credential Flow and few more.
In implicit flow, all the communications are happening through the browser (front channel). An access token is returned directly from the authorization request. Since everything happens on the browser, it’s the most vulnerable to security threats.
Client credential flow is mostly used in the context of authorizing microservices. It’s a back channel only flow to obtain an access token using the client’s credentials.
This blog is a personal note of mine, that I have written by taking help from Okta’s blog and RFC 6749.
What the Heck is OAuth?
OAuth 2.0 Framework — RFC 6749