Secured Access to Client Applications using OAuth 2.0

Why is OAuth2.0 required?
In the traditional client server authentication model, the client (website, mobile application) requests for a protected resource on the server, by authenticating with the server, using the resource owner’s credentials (username and password). To provide third-party applications access to restricted resources, the resource owner shares it credentials with the third-party. This way of communication and access has several problems.
1. Client applications are required to store the resource owner’s credentials for future use, typically a password with free text
2. Servers are required to support password authentication
3. Client applications gain overly broad access to the resource owner’s protected resources, leaving resource owners without any ability to restrict duration or access of limited resources
4. Compromise of any client application results in compromise of end user’s password and all of data protected by that password

How does OAuth 2.0 work?
OAuth2.0 addresses these issues by introducing an authorization layer and separating role of the client from that of the resource owner. OAuth is an open standard for access delegation, commonly used as a way for internet users to grant applications access to the information on other websites but without giving them the passwords. OAuth provides to clients a “secured delegated access” to server resources on behalf of the resource owner. Instead of using the resource owner’s credentials to access protected resources, the client obtains an access token. Access tokens are issued to clients by an authorization server with the approval of the resource owner. The client uses the access token to access the protected resources hosted by the resource server.
Used by companies such as Google, Facebook, Microsoft, Twitter to permit users to share information about their accounts with third party applications or websites.

The application requests authorization to access service resources from the user. If the user authorized the request, the application receives an authorization grant. The application requests an access token from the authorization server (API) by presenting authentication of its own identity, and the authorization grant. If the application identity is authenticated and the authorization grant is valid, the authorization server (API) issues an access token to the application. Authorization is complete. The application requests the resource from the resource server (API) and presents the access token for authentication. If the access token is valid, the resource server (API) serves the resource to the application

An authorization grant is a credential representing the resource owner’s authorization used by the client application to obtain an access token. OAuth 2.0 defines four grant types.
1. Authorization Code: used with server-side Applications
2. Implicit: used with Mobile Apps or Web Applications (applications that run on the user’s device)
3. Resource Owner Password Credentials: used with trusted Applications, such as those owned by the service itself
4. Client Credentials: used with Applications API access

Bottom Line
OAuth2.0 focusses on providing client applications a “secured delegated access” to server resources, on behalf of the resource owner. It is a standard solution for delegation of authority between different applications.