An Introduction to delegation protocol OAuth 2.0
This is the version 2 of the OAuth protocol. It can be referred to as a authorization framework. Google and popular social websites like Facebook and Twitter also uses OAuth2 protocol for authentications and authorizations.
So simply OAuth protocol is a secure authorization protocol that deals with the authorization of third party application to access the user data without exposing their password. eg. (Login with fb, gPlus, twitter in many websites..) all work under this protocol.
Before dive into details about OAuth need to know about authentications and authorizations.
Authentications: Authentication is the process of verifying the identity of a user by obtaining some sort of credentials for example user’s username password combination, and using those credentials to verify the user’s identity.
Authorizations: Authorization is the process of allowing an authenticated user to access resources by checking whether the user has access rights to the system. You can control access rights by granting or denying specific permissions to an authenticated user. So If the authentication was successful, the authorization process starts. Authentication process always proceeds to Authorization process.
So check the overview of OAuth 2 roles, use cases, and flows.
Roles:
OAuth2 defines 4 roles
Resource Owner:User The resource owner is the user who authorizes an application to access their account. The application’s access to the user’s account is limited to the “scope” of the authorization granted (e.g. read or write access).
Resource Server:API server hosting protected data/resources. (for example Google hosting your personal information such as contacts).
From an application developer’s point of view, a service’s API fulfills both the resource and authorization server roles. We will refer to both of these roles combined, as the Service or API role.
Client:Application The client is the application that wants to access the user’s account. Before it may do so, it must be authorized by the user, and the authorization must be validated by the API.
Authorization Server: server issuing access token to the client. This token will be used for the client(application) to request the resource server. This server can be the same as the authorization server for example Google authorization server.
Tokens
When the client application is authorized by the resource owner, the authorization server issues an token. The client application can use that token to access resource server APIs. These tokens are random string generated by the authorization server.
There are two type of token :-
Access token: This token allows a third-party application to access user data on a resource server. This token is sent by the client as a parameter or as a header in the request to the resource server and it has a limited lifetime.
Refresh Token: This token is issued with the access token but unlike the latter, it is not sent in each request from the client to the resource server. The client application can simply use a refresh token to renew access token when it expires.
Access Token Usage: Once the application has an access token, it may use the token to access the user’s account via the API, limited to the scope of access, until the token expires.
Here is an example of an API request, using curl :-
curl -X POST -H “Authorization: Bearer ACCESS_TOKEN” https://api.example.com/v2/$object"
Assuming the access token is valid, the API will process the request according to its API specifications. If the access token is expired or otherwise invalid, the API will return an “invalid_request” error.
Refresh Token Usage: After an access token expires, using it to make a request from the API will result in an “Invalid Token Error”. At this point, if a refresh token was included when the original access token was issued, it can be used to request a fresh access token from the authorization server.
Here is an Example:-
I think we should now have a basic idea of how OAuth 2 works.
