Spring Security OAuth project provides all the necessary API we might need in order to develop an OAuth2 compliant implementation using Spring. Official Spring security oauth project provides a comprehensive example for implementing OAuth2. The code samples of this post is inspired by that examples itself. The intention of this post is to just use bare-minimum functionality required in order to secure our REST API, nothing more. As you, I too am still learning it, so feel free to correct me if something seems not right.

At minimum, you should be aware of four key concepts in OAuth2:

1. OAuth2 Roles OAuth2 defines four roles:

resource owner: Could be you. An entity capable of granting access to a protected resource. When the resource owner is a person, it is referred to as an end-user. resource server: The server hosting the protected resources, capable of accepting and responding to protected resource requests using access tokens. client: An application making protected resource requests on behalf of the resource owner and with its authorization. It could be a mobile app asking your permission to access your Facebook feeds, a REST client trying to access REST API, a web site [Stackoverflow e.g.] providing an alternative login option using Facebook account. authorization server: The server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization. In our example, our REST API can only be accessed via Resource server which will require an access token to be present with request

2. OAuth2 Authorization Grant types An authorization grant is a credential representing the resource owner’s authorization (to access its protected resources) used by the client to obtain an access token. The specification defines four grant types:

authorization code implicit resource owner password credentials client credentials We will be using resource owner password credentials grant type. The reason is simple, we are not implementing a view which redirects us to a login page. Only the usage where a client [Postman or RestTemplate based Java client e.g.] have the Resource owner’s credentials and they provide those credential [along with client credentials] to authorization server in order to eventually receive the access-token[and optionally refresh token], and then use that token to actually access the resources.

A common example is the GMail app [a client] on your smartphone which takes your credentials and use them to connect to GMail servers. It also shows that ‘Password Credentials Grant’ is best suited when both the client and the servers are from same company as the trust is there, you don’t want to provide your credentials to a third party.

3. OAuth2 Tokens Tokens are implementation specific random strings, generated by the authorization server and are issued when the client requests them.

Access Token : Sent with each request, usually valid for a very short life time [an hour e.g.] Refresh Token : Mainly used to get a new access token, not sent with each request, usually lives longer than access token. A Word on HTTPS : For any sort of Security implementation, ranging from Basic authentication to a full fledged OAuth2 implementation, HTTPS is a must have. Without HTTPS, no matter what your implementation is, security is vulnerable to be compromised. 4. OAuth2 Access Token Scope Client can ask for the resource with specific access rights using scope [want to access feeds & photos of this users facebook account], and authorization server in turn return scope showing what access rights were actually granted to the client [Resource owner only allowed feeds access, no photos e.g.].