From this time, I will explain how to realize REST API authentication / authorization using OAuth 2.0 authorization code grant flow using Spring Security OAuth (+ Spring Boot) in several times (probably about 3 to 5 times). To do. While saying ... I'm not familiar with OAuth 2.0 either ... There may be a wrong explanation (not bad ...): sweat_smile: If you have a wrong explanation, please leave a comment (correction request). Please! !!

So, this time of the first time ... I would like to briefly explain what OAuth 2.0 is (= review). By the way ... I'm not talking about Spring Security OAuth and Spring Boot this time ~: stuck_out_tongue_winking_eye:

Part 2: Making an app for the time being

What is OAuth 2.0?

First, let's take a quick look at OAuth 2.0. OAuth 2.0 is an authorization framework that allows a service provider to provide an appropriate access range (scope) to a client when providing a WEB resource to a "third-party application (hereinafter referred to as a client)". , Some RFCs have technical specifications.

In addition to the above, there is also an RFC for using JWT (JSON Web Token) as an access token.

In this entry, I think that you should know at least if you use OAuth 2.0, and I would like to briefly explain the architecture of OAuth 2.0 focusing on the contents (role, authorization grant, scope, access token, refresh token, etc.). I will.

Role

OAuth 2.0 defines the following four roles that appear when performing authentication / authorization.

roll	Description
Resource Owner	The owner of the resource, responsible for authorizing access to the resource (providing an authorization grant). Service users (humans) often play this role.
Resource Server	It is responsible for providing the resources of the resource owner under appropriate access control (access control using the scope assigned to the access token). The service provider's web server plays this role.
Authorization Server	Resource owner authentication, authorization from resource owner(Obtaining a licensed grant), Responsible for issuing access tokens corresponding to authorized grants. The service provider's web server plays this role.
Client	Responsible for accessing protected resources on behalf of the resource owner using the access token corresponding to the authorization grant provided by the resource owner. Web applications, user agent-based client applications(JavaScript etc.), Native applications, etc. play this role.

The following is a pictorial representation of the interaction between roles (protocol flow).

spring-security-oauth-oauth2.0.png

Authorized grant

In OAuth 2.0, granting access to resources is called "authorization grant", and the following four types are defined as grant types.

Grant type	Description
Authorization Code	The resource owner issues an authorization code (a code indicating that access to the resource is authorized) via the authorization server and provides it to the client. Since the client exchanges the access token with the authorization code provided by the resource owner, the resource owner's credentials (user name and password) are not passed to the client, which is the most secure grant type.
Implicit	The point that the resource owner allows access to the resource via the authorization server is the same as the authorization code grant, but in the case of the implicit grant, the access token is issued directly after authorization. As with the authorization code grant, the resource owner's credentials (user name and password) are not passed to the client, but the security is lower than the authorization code grant because the client is not authenticated.
Resource Owner Password Credential	Issue an access token by passing the resource owner's credentials (user name and password) as an authorization grant. Since the resource owner's credentials must be passed to the client, the risk of misuse of the resource owner's credentials increases for untrusted or malicious clients.
Client Credential	An access token is issued by passing the client's credentials (client ID and password) as an authorization grant. This is a grant type used when the client itself is like a resource owner.

scope

OAuth 2.0 uses the concept of scope to limit the resources that clients can access. The scope that can be handled is managed by the authorization server, and the client can specify the "scope that you want to be authorized" when requesting the issuance of the authorization code or access token.

Access token

In OAuth 2.0, the access token is exchanged with the authorization grant provided by the resource owner, and when accessing the resource, the access token is passed for authentication / authorization. The access token can have an expiration date, and when the expiration date expires, it is necessary to obtain authorization from the resource owner again. If the expiration date is short, the usability of the application user will be low, and if the expiration date is long, the risk of misuse due to the leakage / leakage of the access token will increase.

Refresh token

Is there a way to reduce usability without increasing the risk of access token leakage? ... of course there is! !! The "refresh token" solves this problem at once. A refresh token is a token used to reissue an access token when the access token has expired. By using the refresh token, you can issue a new access token with the same scope as when you obtained the access token, so you can save the trouble of asking the resource owner to reauthorize. You can also set an expiration date for the refresh token, and once the refresh token expires, you will not be able to reissue the access token (= you will need to obtain authorization from the resource owner again).

Access Token and Refresh Token Expiration Strategy

It seems to be a common practice to keep the usability of users without increasing the risk of access token leakage by shortening the expiration date of the access token and extending the expiration date of the refresh token.

Authorization code grant flow flow

The introduction has become a little long, but from here, let's see how to access resources when using the "authorization code grant flow" dealt with in this entry.

spring-security-oauth-oauth2.0-code-grant.png

Item number	Description
(1)	The resource owner requests the display of an arbitrary page (page that accesses the resource server) provided by the client via the user agent. The client responds with a redirect instruction to the authorization screen of the authorization server in order to obtain authorization from the resource owner.
(2)	The user agent is the page instructed by the client(Authorization screen of authorization server)Make a display request (redirect). The authorization server responds with a screen for obtaining authorization from the resource owner via the user agent.
(3)	The resource owner makes an approval request for the authorization request requested by the client via the user agent. The authentication server issues a code (authorization code) indicating that the resource owner has authorized access to the resource, and then again.(1)The resource owner responds with a redirect instruction to the page of the client that made the display request. In addition, the authorization code is added to the parameter to the URL for redirect and linked.
(4)	The user agent makes a display request (redirect) for the page instructed by the authorization server (the page of the client that the resource owner first requested to display). The client gets the resource of the resource owner from the resource server (details 5),(Refer to 6), and then respond with a page that embeds the acquired resource information.
(5)	The client acquires an authorization code from the request parameter, specifies the acquired authorization code, and makes an access token issuance request. The authorization server issues an access token after verifying the validity of the authorization code, and responds the access token to the client.
(6)	The client calls the REST API of the resource server by specifying the access token obtained from the authorization server. After verifying the validity of the access token and scope, the resource server calls the REST API process and responds to the client with the resource returned from the REST API.

Summary

Part 1 was a quick review of OAuth 2.0. The content described in this entry is only a part of the specifications defined by OAuth 2.0, but we would appreciate it if you could roughly imagine the flow of the authorization code grant flow. (I'm not confident about it ...: sweat_smile :) Next time, I would like to use Spring Security OAuth (+ Spring Boot) to actually experience REST API authentication / authorization using authorization code grant flow. (I don't know when it will be, but next time ~)

Let's experience the authorization code grant flow with Spring Security OAuth-Part 1: Review of OAuth 2.0