oAuth 2.0 is a token base authentication & authorization mechanism. Here the authorization refers to authorizing the app (angular app / react app / any other browser based app / mobile) to access the protected resources on the server. These resources are provided through a well-defined REST API by the resource server
It must also be noted that it is more than authorizing the app; you may also want to authenticate the user who is using the app. In such a case you will authenticate the user on the server and return the token back to the client app.
There are different use cases and scenarios of using oAuth 2.0. The way you would use it with Facebook is different than the way you would use it for your own client app with your very own server side resources. In this article I intend to describe the use case where-in you want to provide authorized access of your server side resources to the user who would log on to your own app.
At CIGNEX, we implement Liferay portals and have been implementing various different use cases of oAuth 2.0
Here is the use case - You have resources like Blog, Wiki, Message Board, Polls, and Surveys etc. These resources are being managed by business & data logic specific components implemented in java (not necessary). You have defined RESTful API(s) to access these resources. You also have an Angular app that consumes these APIs and access the resources. While blogs can be viewed by everyone, creating and updating of blogs must be allowed only to authenticated and authorized users. So your Angular app would certainly have a feature where-in the user logs on to the system and gets the access to the resources he is entitled to create and update. The flow will be as follows
- There is a specific clientId and secret provided for a given app (your own app or a 3rd party app). The clientId here represents client app (mobile app / browser based app)
- The client makes a POST request to the auth server with: the clientId, secret, username & password. The clientId and secret is passed as basic authorization (Authorization : Basic << the base64 encoded clientId and secret >> ) whereas the username and password are passed as parameters of the request
- The server validates the clientId & secret to validate that the token is being requested by a legitimate client and also validates (user authentication) the username and password to make sure that the user using the app is allowed to do so. Very importantly : the server returns the token back on successful authentication
- The client stores the authentication token in either cookie or local storage and keeps sending the same token in each request to access the resource.
- The resource server now will validate the token and allow access to the resource.
There are various grant types with respect to oAuth 2.0 request. The above scenario mandates “password” grant type. So grant_type is yet another parameter that is passed in the POST request.
The auth-server and resource-server may be one single application running on the server or else they may be two different applications… it is how you may want to architect things. Ideally the authorization server is a different service running on a different machine. This facilitates separation of concerns and also allows auth-server implementation to evolve all on its own.
Besides this, I have never found an article on oAuth 2.0 as good as this: http://www.bubblecode.net/en/2016/01/22/understanding-oauth2/#Authorization_grant_types
We have extensive experience on Liferay, micro-services based solutions, out systems and Salesforce. You have a consulting, development or a support project! Give us a shout for a 15 mins of free consultation with our senior architects.
