Introduction to OAuth 2.0 Protocol
This blog post will explain the basics of OAuth 2.0 Concept!
What is OAuth 2.0 ?
OAuth2 is the version 2 of the OAuth protocol (Also called as Framework). OAuth protocol allows third-party applications to grant limited access to the HTTP service, either on behalf of a resource owner or by granting the third-party application access in its own name. Access is requested by a client. This can be for example a website or a mobile application.
Roles
- Resource Owner: An entity that can grant access to a protected resource. If the resource owner is a person, he/she is referred to as End user.
- Resource Server: The server that hosts and can accept the protected resources and respond to requests for protected resources using access tokens (for example Google hosting your profile and personal information).
- Client : An Application requesting access to a resource server on behalf of the resource owner and with his/her authority.(it can be your PHP website, a JavaScript application or a mobile application).
- Authorization Server:The server sends access tokens to the client after successful execution Authentication of the resource owner and receipt of the authorization.
Tokens
Tokens are random strings that are generated and output by the authorization server when the client requests them.
There are 2 types of token:
- Access Token:This is especially important because it prevents third-party application access to user data. This token is sent by the client as a parameter or header in the request to the resource server. It has a limited lifetime, which is set by the authorization server. It needs to be kept confidential, but we’ll find that this is not always possible, especially if the client is a web browser that sends requests to the resource server via Javascript.
- Refresh Token: This token is issued with the access token, but unlike it, it is not sent from the client to the resource server on every request. It only serves to be sent to the authorization server to renew the access token after expiration.
Access token scope
The scope is a parameter that limits the rights of the access token. This is the authorization server that defines the list of available areas. The client must then send the areas that it wants to use for its application to the authorization server during the request. The smaller the scope, the greater the likelihood that the resource owner authorizes the access.
HTTPS
OAuth2 requires the use of HTTPS for communication between the client and the authorization server, because between the two confidential data are transmitted (tokens and possibly resource owner credentials). In fact, you do not have to do this if you implement your own authorization server, but you need to know that this will open a major security hole.
Register as a client
Because you want to use OAuth2 to retrieve data from a resource server, you must register as the authorization server’s client.Each provider is free to allow this according to a method of his choice.The protocol defines only the parameters that must be specified by the client and that must be returned by the authorization server.
Here are the parameters (they can vary depending on the provider):
Client registration
- Application Name: Name of the application
- Redirect URLs:URLs of the client for receiving authorization code and access token
- Grant Type(s): Authorization types that will be used by the client
- Javascript Origin (optional): the hostname that will be allowed to request the resource server via XMLHttpRequest
Authorization server response
- Client Id: Unique random string
- Client Secret: Secret key that must be kept confidential
Abstract Flow
- The application requests authorization to access some protected resources on the server where the user is already authenticated and authorized.
- If the user has authorized the request, the application will receive an authorization grant upon approval.
- The application requests an authorization token from the authorization server, providing authentication of its own identity and authorization granted to the user.
- If the identity of the client application is authenticated and the authorization grant is valid, the authorization server issues an access token for the application to complete the authorization.
- The client application requests the resource from the resource server by presenting the access token for authentication
- If the access token is valid, the resource server provides the resource for the client application
The actual process, however, depends on which type of grant type is used.
Authorization grant types
OAuth2 defines four types of grants depending on the location and type of client involved in obtaining an access token.
- Authorization Code Grant - Most commonly used for server-side applications. This is a redirection-based flow, meaning the application must be capable of interacting with the client browser to handle re-routes.
- Implicit Grant - Used for single page web applications and mobile applications, where the client secret confidentiality is not guaranteed. This flow does not authenticate the identity of the application, and relies on the redirect URI provided while registering.
- Resource Owner Password Credentials Grant - Where the user provides their username and password credentials directly to the client application. This should only be used if the application is trusted by the user (generally a mobile version of the same vendor of the web app).
- Client Credentials Grant - Provides an application a way to access its own resources and is used by client applications to obtain an access token outside of the context of a user.
How to choose OAuth 2.0 grant type
Deciding which grants to deploy depends on the type of client the end-user is using and the experience you want for your users.
- First Party or Third Party Client — A first-party client is a client that you trust to process the end-user credentials. A third party client is a client that you don’t trust.
- Access Token Owner — An access token is a permission granted to a client to access some protected resources.If you authorize a computer to access resources and do not require a user’s permission to access those resources, you should implement client credentials. If you need a user’s permission to access resources, you must determine the client type.
- Client Type — Depending on whether or not the client is capable of keeping a secret will depend on which grant the client should use. If client is a web application that has a server side component then you should implement the authorization code grant.If the client is a web application that has runs entirely on the front end you should implement the password grant for a first party clients and the implicit grant for a third party clients. If the client is a native application such as a mobile app you should implement the password grant.
Click to my next blog post How to Consume GMail API Using OAuth2.0.
