How it works...

Through this recipe we will be able to access the user's resources, which must be available at http://localhost:8080/api/profile if the application is running correctly. Supposing you have followed all the steps in this recipe and the application is running, after retrieving an access token, you would be able to send a request to the profile endpoint to obtain the following JavaScript Object Notation (JSON) result:

{
 "name": "adolfo",
 "email": "adolfo@mailinator.com"
}

But to access this endpoint, you have to present a valid access token retrieved after the user's approval to share her profile. The access token in this case will be validated because of the Resource Server configuration. By adding the @EnableResourceServer annotation as we did for the OAuth2ResourceServer class, we are importing some configurations which will add the filter OAuth2AuthenticationProcessingFilter within the Spring Security's FilterChain configuration. That's the filter that will be in charge of starting the access token validation process for any endpoint that matches the /api/** pattern.

In addition to the Resource Server configuration, we added the Authorization Server configuration through the OAuth2AuthorizationServer class. By looking at the OAuth2AuthorizationServer class, you might realize that it does not contain a lot of code. It's really easy to configure an Authorization Server with Spring Security OAuth2 Framework, but there are a lot of things happening behind the scenes.

By adding the @EnableAuthorizationServer annotation, we are importing some important configuration classes which are AuthorizationServerEndpointsConfiguration and AuthorizationServerSecurityConfiguration. The AuthorizationServerEndpointsConfiguration class, has an important dependency for an OAuth 2.0 Authorization Server to work. That's the AuthorizationServerEndpointsConfigurer class, which declares the following beans:

• AuthorizationEndpoint
• TokenEndpoint
• CheckTokenEndpoint

Those beans declare OAuth 2.0 related endpoints as endpoints for authorization flow and for access token and refresh token requests. If you want to deeply understand how each endpoint works, I encourage you to read the source code of Spring Security OAuth2 available at GitHub. Running the application, we can interact with some of the OAuth 2.0 declared endpoints. To see how the process works, start the application through your IDE or by running the mvn spring-boot:run command. After the application is running, point to the following URL through your browser:

http://localhost:8080/oauth/authorize?client_id=clientapp&redirect_uri=http://localhost:9000/callback&response_type=code&scope=read_profile

As we are using the Authorization Code grant type, we need to redirect the Resource Owner to the authorization page which is declared by the /oauth/authorize endpoint. Notice that we are sending the client_id, redirect_uri, response_type, which must be code and the scope as read_profile. If you want to better understand each of these parameters you can read about the Authorization Request section of the OAuth 2.0 specification at https://tools.ietf.org/html/rfc6749#section-4.1.1. Note that we are not sending the important state parameter to avoid CSRF attacks (we will see more of this in Chapter 8, Avoiding Common Vulnerabilities).

After going to the authorization endpoint, the Authorization Server must authenticate the Resource Owner as per the OAuth 2.0 specification:

Enter the User Name and Password declared in the application.yml configuration file, which in my case is adolfo and 123 respectively. After clicking on Log In, you will be redirected to the user's consent page where the Resource Owner can choose which scopes to grant permission to for third-party application (client). The following page is generated automatically by Spring Security OAuth2 but can easily be replaced by a custom one:

The next step is to click on Authorize so that the user can be redirected back to the client application, which must be specified by the redirect_uri attribute. When redirected back to the redirection URI, the Authorization Server must issue an Authorization Code which depicts the user's approval granting permission for the specified client on the specified Resource Server. The Authorization Code comes as a query string parameter defined as code as follows:

http://localhost:9000/callback?code=5sPk8A

The previous URL has the code randomly generated by the Authorization Server which must be used by the client to request for an access token at the server side. To request an access token using the previous received Authorization Code, run the following CURL command through any terminal (pay attention to the code parameter which must be different for you):

curl -X POST --user clientapp:123456 http://localhost:8080/oauth/token -H "content-type: application/x-www-form-urlencoded" -d "code=5sPk8A&grant_type=authorization_code&redirect_uri=http%3A%2F%2Flocalhost%3A9000%2Fcallback&scope=read_profile"

Note that we need to use the same redirect URI we have sent before on the authorization request. As per the OAuth 2.0 specification, the redirect URI must be sent if you have sent the redirect URI on the authorization request. After running the previous CURL command, you should receive something like this:

{
   "access_token": "43c6f525-041f-43c8-b970-  82ba435d3c2c",
   "token_type": "bearer",
   "expires_in": 43199,
   "scope": "read_profile"
}

Let's try to access the user's profile by presenting the retrieved access token to the /api/profile endpoint, as follows:

curl -X GET http://localhost:8080/api/profile -H "authorization: Bearer 43c6f525-041f-43c8-b970-82ba435d3c2c"

If everything is running as expected, you should see the following content in the output:

{
   "name": "adolfo",
   "email": "adolfo@mailinator.com"
}