How it works...

Everything we did when using the @EnableAuthorizationServer and @EnableResourceServer annotations configures our current application, implicit-server to support both OAuth 2.0 token validation as well as the OAuth 2.0 endpoints for authorization and token requests. The main difference now is that we have changed the authorized grant type to use, so the authorization flow will be a little bit different. In addition, we have the fact that we don't need to send a request to /oauth/token for this grant type because the access token is retrieved implicitly, as defined by the name of the grant type by itself.

With the application running, go to the following authorization URL which is sending the response_type parameter as token instead of code:

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

Note that we are not encoding the parameters using URL encoding; that's because of didactical purposes. When implementing a real application, consider encoding all the parameters. After going to the authorization endpoint, the Authorization Server will authenticate the Resource Owner by asking for the User Name and Password, as shown in the following screenshot:

Enter the User Name and Password, which in my case was adolfo and 123 respectively. After being authenticated, the user will be sent to the user's consent page, as follows:

Select the required scope, which is read_profile, and click on Authorize so you get redirected back to the redirect URI callback, as defined by the redirect_uri parameter. As you might see in the following code, the access_token is retrieved as a URL fragment in addition to the state parameter that we sent before when redirecting the user to the Authorization Server's authorization endpoint:

http://localhost:9000/callback#access_token=a68fce80-522f-43ee-85d4-6705c34e555c&token_type=bearer&state=xyz&expires_in=119

Along with the access_token and the state parameter, we also receive back the token_type and expires_in parameter. These parameters were also present when requesting for an access token when using the Authorization Code grant type. But when using the Implicit grant type, it's important to bear in mind that this grant type is not allowed to issue a refresh token as per the OAuth 2.0 specification. This behavior makes sense because as the user must be present when using an application that runs within the browser, then the user can always authorize the third-party application again if needed.

Moreover, the Authorization Server has plenty of conditions to recognize the user's session and avoid asking the Resource Owner to authenticate and authorize the client again. Another reason for not issuing a refresh token for the Implicit grant type, is because this grant type is aimed at public applications that are not able to protect confidential data, as is the case with refresh tokens.

Now, try to retrieve the user's profile through the /api/profile endpoint using the previously issued access token and the user's profile should be returned as JSON content.