How it works...

This recipe presents a particular case of OAuth 2.0 grant types which allows for any registered client to access resources on its own behalf. All the previous recipes, described how to use grant types which allow a third-party application to access resources on behalf of the Resource Owner. Because of the purpose of this grant type, we have created a fictitious API that provides one endpoint so the client could retrieve all registered users on the OAuth 2.0 Provider.

Almost all the configurations for the Authorization Server and Resource Server were similar to the other grant types. The main difference now is that we don't need any redirection URI. In addition, we also have to set up the correct grant type to use, as presented in the following code:

 clients.inMemory()
   .withClient("clientadmin")
   .secret("123")
   .authorizedGrantTypes("client_credentials")
   .scopes("admin");

Let's start the application to understand how to interact with the main pieces of this OAuth 2.0 Provider. When using the Client Credentials grant type, we do not have any user interaction so we don't have the authorization flow, but we just have to request for an access token for sending the Client's Credentials and the grant type, which is client_credentials, as presented in the following CURL command line:

curl -X POST "http://localhost:8080/oauth/token" --user clientadmin:123 -d "grant_type=client_credentials&scope=admin"

After running the previous command, you should see something similar to the following:

{
    "access_token":"f6f81a52-7920-4f95-a83b-72fbfb5188c5",
    "token_type":"bearer",
    "expires_in":43157,
    "scope":"admin"
}

It's important to note that when using the Client Credentials grant type, as per the OAuth 2.0 specification, the Authorization Server should not issue a refreshed token because there is no reason to worry about the user experience in this case. When using Client Credentials, the client by itself is able to request a new access token in case of an expiration.

To use the access token, the process is the same because, as you might already know, it doesn't matter how the access token was obtained. So, to make a request for an OAuth 2.0 protected resource, you just need to send the HTTP authorization header with the retrieved access token as follows:

curl "http://localhost:8080/api/users" -H "Authorization: Bearer f6f81a52-7920-4f95-a83b-72fbfb5188c5"

After running the previous command, you should see the following result:

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

This recipe shows that you can still protect the other resources so that they can be accessed safely using another authentication mechanism, such as HTTP Basic Authentication or any other. To exemplify it, we have declared the configuration class WebSecurityConfiguration which extends from WebSecurityConfigurerAdapter. As you can see in the following code, all the endpoints that match with /user/** pattern would be protected using HTTP Basic Authentication:

.antMatcher("/user/**").httpBasic()

Note that you are not able to make a request to the /user endpoint using the previously issued access token because this endpoint is not protected by OAuth 2.0, but by HTTP Basic Authentication. The right way to retrieve the user's profile now is to send the following request:

curl "http://localhost:8080/user" --user adolfo:123