OAuth2.0 is nothing but an authorization framework. To clarify it enables our third-party application to obtain limited access to HTTP services. In other words, it allows a third-party application to access limited resources on its behalf.
Why we need : OAuth2.0
There is a buzz of OAuth2.0, therefore, everyone is really curious about it. Those who know already adapted this. With the bust of the smartphone, there are so many applications that make an enormous network and because got one problem. In short how to manage data for all these applications? There exactly comes the role of OAuth2.0 where instead of handing data for all applications separately third party applications like google will be handling this data.
This post is written to understand the concept of OAuth2.0 in simple terms. For now google, facebook, github, etc provides these services, I am sure amazon will also be adapting it sooner.
Advantage of OAuth2.0
- OAuth2.0 uses SSL to save user access token so it ensures by a cryptographic protocol
- Allows limited access to the user data for your third party application by providing authorization token
- Moreover, it can share the user’s data without releasing personal information
- It is easier to implement and provides stronger authentication
- As it is a kind of centralized authentication for all the applications that makes it user-friendly
- Any kind of data breach happens by your application you must have to pay a certain amount of fine as a penalty. If you are using OAuth2.0 all the data security headache is of that application only and not yours now.
End user perspective
When you visit a web application like bookmyshow which uses OAuth2.0. The moment you click on signup it will popup an authentication page which gives user options to either signup using google or facebook.
If your user gives valid credential it will return an access token for authorization purpose the redirects to bookmyshow with some user data like name, age, profile image, etc. Now, whenever any sub-application of bookmyshow asks for user data with that access token google authorizes it with the help of that token and then gives limited access to the resources.
- User will access your client application
- Our client here will act as a third party application and request the authorization server with client id. You can get a client id and client secret id by registering your application as an OAuth2.0 client to a service provider like google or facebook.
- Then the authorization server like google asks the user for its credentials.
- If authenticated then google will authorize your application to have limited access to user data by providing an access token.
- Now whenever your application or any associated application wants to access user data. It has to access the resource server by providing the access token which then validated by the server. If valid then send data in response.
I hope you guys are now familiar with the concept of OAuth2.0 the goal of this blog post is to act as an add on the series of the blog post where we are automating OAuth2.0 using rest assured. To more about rest assured click here.
Scenario1: The front-end security token may need to be replaced with a back-end token that is understood by a third-party API provider. Another characteristic of this scenario is that the OAuth 2 access token presented to the API gateway should contain the minimum information needed to securely convey the authenticated end user’s security context.
Scenario2: There is a common API gateway proxying requests to application-owned APIs and third-party API providers. The API gateway is playing the role of mediator between a common front-end security model and potentially multiple unique back-end security models of the varying API providers. For example, the original end-user security context could be passed to the back-end API provider.
References and external links :