OAUTH Overview
Why OAUTH ?
In the traditional client-server authentication model, the client makes a Request to secured resource on the server by authenticating with the server using the resource owner’s credentials.
In this case, since third-party applications needs resource owner’s credentials to access the secured resources.
So Resource owner shares his/hercredentials with the third party.
This way resource owner’s credentials are compromised with third party and hence Resource owner doesn’t have any control on how Third party uses his/her credentials.
This problem is addressed by OAUTH along with some additional benefits.
Let’s understand the above problem with below diagram
Lets understand “Without OAuth” Flow
xyz.com asks for the user to login into xyz.com through his/her Facebook credentials.
This is generally provided to avoid the registration process with xyz.com
As soon as user clicks on login with facebook, xyz.com presents a login page of its own to collect facebook credentials.
User provides facebook credentials to xyz.com , now xyz.com gets the user’s details from Facebook using these crednetials.
In this case, user has compromised his/her facebook credentials with xyz.com even though xyz.com displays a message saying that
credentials will not be misused.
Let’s understand the solution for the above problem by OAUTH with below diagram
Lets understand “With OAuth” Flow
xyz.com asks for the user to login into xyz.com through Facebook credentials.
As soon as user clicks on login with facebook, xyz.com redirects to facebook login page
Since it is a Facebook Login page, User can trust facebook easily and enters facebook credentials in facebook login page,
Now facebook page will asks for the permission to provide access to required details and same details will be sent back to xyz.com.
In this way, user’s credentials of facebook is not shared with xyz.com and still user can login to xyz.com without registering in xyz.com.
Now Let’s understand this in technical terms how OAUTH makes it happen
What is OAUTH?
The OAuth is an authorization framework which allows third-party applications to obtain limited access to an HTTP service, either on behalf of a resource owner or by allowing the third-party application to obtain access on its own behalf.
Access will be requested by a client,for example, it can be a web application, desktop application or mobile application.
Many applications in real world have implemented OAUTH to expose their secured HTTP services, some of which are Google, Facebook and GitHub.
Any third party application who wants to access these secured HTTP services has to follow the OAUTH protocol standards.
In simple words,
When any third party application (example xyz.com) tries to access the secured service (example facebook profile)
OAUTH provides different set of credentials to thrird party instead of actual facebook’s credentials.
These different set of credentials are access token and refresh token in OAUTH words.
Client use these credentials to communicate with the secured service.
OAUTH defines 4 roles
1. Resource owner
As the name indicates, it’s the owner of the resource who is capable of granting access to a protected resource.
Example : It could be end user(owner of facebook profile)
2. Resource server
The server hosting the protected resources, capable of accepting and responding to protected resource requests through HTTP service using access tokens.
Example : Facebook server
3. Authorization server
The server issuing access tokens to the client only after successfully authenticating the resource owner and obtaining authorization.
Example:Facebook server
Resource server will be same as authorization server in most of the cases.
4. Client
It’s an application making requests to protected resource on behalf of the resource owner with its authorization.
Example:
It could be mobile app asking our permission to access our Facebook feeds
REST client trying to access a secured REST API
Web site providing an alternative login option using Facebook or Gmail account.
Tokens
Tokens are random strings generated by authorization server and they are issued to client whenever client request for it using authentication.
Types of tokens
1. Access Token
These are the credentials used by client to access the secured resource.
Access tokens sent with each request and valid for very short time
2. Refresh token
These are the credentials used by client to obtain the access token whenever the current access token becomes invalid or expires.
Refresh tokens will not be sent with each request and they usually live longer than access tokens.
Refresh tokens are issued by authorization server to client while sending access token for the first time.
1. Client makes a request to resource owner to get authorization grant.
It can be made directly to resource owner or indirectly via authrorization server.
2. If resource owner authorizes the request, Client receives the authorization grant
which is a credential representing the resource owner’s authorization expressed using one of the 4 defined Grant types.
3. The client requests an access token from the authorization server by presenting authentication of its own identity, and the authorization grant.
4. If the client identity is authenticated and the authorization grant is valid, the authorization server issues an access token to the client.
5. The client requests the secured resource from the resource server by presenting the access token.
6. The resource server validates the provided access token, and if valid, serves the request.
Authorization Grant Types
An authorization grant is a credential representing the resource owner’s authorization. (to access its protected resources)
It is used by the client to obtain an access token.
The OAUTH specification defines four grant types based on the nature of the client requesting the access token
1. Authorization code grant
The authorization code is obtained by using an authorization server as an intermediary between the client and resource owner.
client will redirect the resource owner to authorization server, then authorization server authenticate the resource owner and obtain the permission then it redirect resource owner back to client by sending authorization code to Client.
Example:
Stackoverflow site allows user to login with Facebook
Stackoverflow takes resource owner to facebook login page
Facebook login page collects the resource owner credentials and authenticate the resource owner and takes permission from resource owner.
Facebook send the authorization code to stackoverflow.
Stackoverflow will use this authorization code to obtain the access token and get the user information from facebook.
When to use this Grant type?
If client is also a web server as it allows to obtain the access token using authorization code and can be renewed with refresh token.
2. Implicit grant
In this case, Instead of issuing an authorization code, client will be issued an access token directly.
This grant type does not allow the issuance of a refresh token.
It improves the responsiveness as it reduces the trip to get the access token.
When to use this Grant type?
It is typically used when the client is running in a browser using a scripting language such as Javascript.
3. Resource owner password credentials grant
In this case, Resource owner’s credentials(username and password) will be shared with the client for the first time
Then client send these crednetials to authorization server,then authorization server provides the access token back to client.
Now on wards client will use this access token to communicate with authorization server.
When to use this Grant type?
Since credentials are shared with the clients, it should be used only when there is a high degree of trust between the client and the resource owner.
When both the client and the servers are from same company,we can easily trust to share the credentials, as we are not providing our credentials to any third party.
Example: If cient is a facebook app on our smart phone then we can share our facebook credentials with facebook app to connect to facebook server.
4. Client credentials grant
Secured resources are under the control of client and hence client is a resource owner here.
So there is no need to obtain any authorization from the end user.
When to use this Grant type?
This should be used when client itself is a resource owner.
Example:
Client has stored some files in google cloud storage.
Client has to call the google API to access these files.
So client authenticates with the google authentication server and then obtain an access token which can be used further to access the files.
Lets see the practical implementation of OAuth with Spring security in Spring security OAuth article.
Hi Sir, Thank you for this explanation. I recently created new REST based extension for the middle ware or clients to interact with hybris.
The only condition was to have user id and password authenticated by decoding the received credentials and once it is authenticated, the service created from hybris end which is exposed is allowed to post the data by client,
so in this case can you please explain briefly as what needs to be added in the spring-security.xml under config folder.
I am new to this implementation, so any help is appreciated.
Thanks
in my case i have to use point 3 mentioned here:
3. Resource owner password credentials grant
Could u please explain the changes to e made in security file for this implementation