The Evolution of Authorization: A Brief History Leading Up to OAuth 2.0

When the Internet was first created, the HTTP protocol was a kind of rule to quickly exchange information. Servers simply prepared data and responded to requests without storing client information, which was known as the stateless characteristic.

However, as technology progressed, servers needed to identify who the client was. For example, shopping websites needed to display different items in each client's shopping cart. This led to the creation of various login authentication technologies.

The first login authentication technology, cookies, stored the user ID and password on the server. When the client sent the ID and password to the server, the server checked them.

Cookies are typically stored in the HTTP URI's header, which is easy to access during information requests. Therefore, attackers often intercepted the information in the middle of the request and obtained the user ID and password.

Session

The session created a storage area to store the client's user ID and password and generated a unique Session ID to save it. When the client logged in, the client sent the Session ID instead of the user ID and password to the server, which used it to identify the client.

Since the user ID and password were only sent once, it was difficult to intercept them. Also, the Session ID was not related to the user ID and password, which made it more secure than cookies. However, it was still possible to log in using the Session ID, so security was still not enough.

To improve security, the Session ID was given an expiration time. However, it was inconvenient for clients and not very effective.

Access Token

Next, the Access Token was created. Like the Session ID, it is used for authentication, but the Access Token collects and encrypts the necessary information for authentication. This information is usually stored using the JSON Web Token (JWT) method.

JWT (JSON Web Token) Components

[Header].[Payload].[Signature]

Header: Contains the type and encryption method of the Access Token.
```
  {
    "typ": "JWT",
    "alg": "SHA256"
  }
```
Payload: Contains the necessary information for authentication, such as the token creation time, activation date, expiration date, etc. It does not contain client-related information (such as ID and password).
```
  {
    "sub": "1",
    "iss": "ori",
    "exp": 1636989718,
    "iat": 1636987918
  }
```
Signature: A string created using the SHA256 algorithm specified in the header, using the information in the payload and the server's private key. This is used to authenticate the token, so if the token is tampered with, it can be detected immediately.
```
  {
    "SHA": "9F69FA131C4CA518D3CCE296013D9A3C2B4AA63CA02583C8B6F1F7F354A1D874"
  }
```

Access Token and Refresh Token

One problem with Access Tokens is that they cannot create a new token before the expiration of the current token because the encryption uses an expiration date. However, if the expiration date is set to a short period of time, it is inconvenient for clients. This led to the creation of the Refresh Token.

Access Tokens are issued with a short expiration date, while Refresh Tokens are issued with a long expiration date. When the Access Token expires, the client uses the Refresh Token to authenticate and obtain a new Access Token.

Since the Refresh Token is only sent to the server when the Access Token expires, it is difficult to intercept. Also, since Access Tokens are frequently reissued, it becomes more difficult to intercept them.

OAuth (Open Authorization) 1.0

OAuth 1.0 added another application to protect IDs and passwords. This application was used as an independent service for user authentication and was called the consumer.

User: User

Service provider: Google OAuth Service

Consumer: Twitter

The user attempts to log in to Twitter.
Twitter requests a Request Token from Google OAuth Service.
Google OAuth Service checks the Key and Secret sent by Twitter and generates a Request Token.
Twitter shows the login page through Google OAuth Service (redirect).
The user's login information (ID and password) is sent to Google OAuth Service.
Google OAuth Service checks the Request Token and the ID and password (login authentication).
Google OAuth Service informs Twitter that the authentication was successful.
Twitter requests an Access Token from Google OAuth Service since the user has been authenticated.
Google OAuth Service generates and sends an Access Token to Twitter.
Twitter gives the user the Access Token. Connection complete.
The user logs in using the Access Token until it expires.

In summary, OAuth 1.0 is a way for the user (User), the site the user wants to use (Consumer), and another web service that holds user information (Service Provider) to interact with each other to function. However, this method is complicated to implement, and the lack of Refresh Token means that a new token cannot be created before the expiration of the existing Access Token. Additionally, authentication was only possible through web pages.

OAuth (Open Authorization) 2.0

Disadvantages of OAuth 1.0	Improvements in OAuth 2.0
Lack of security during communication	Use of HTTPS instead of HTTP
Too complex	Simplification of functionality
Inability to issue new tokens before the expiration of access tokens	Introduction of Refresh Tokens
Login authentication only possible through web pages	Expansion of login authentication methods

In addition, the separation of the server responsible for login authentication and the server that processes user requests made it difficult for Access Tokens, user IDs, and passwords to be compromised.

Resource Server	A server that manages resources and responds to requests with an Access Token
Authorization Server	A server that authenticates clients and issues tokens for clients to access services on the resource server
Resource Owner	A user who owns an account on the resource server
Client	A website that uses the resource server's API to retrieve data
Access Token	A token that allows requests for resources to the resource server
Refresh Token	A token that allows the client to request a new Access Token from the authorization server

Authorization Code Grant

Recommended usage
High level of security: Access Token is not directly transmitted to the client, preventing potential leaks
Generally used on the backend server

The user sends their ID and password to the authorization server via the client. If the login is successful, the authorization server issues an authorization code to the user.
The client sends the authorization code to the authorization server and requests an Access Token. The authorization server verifies the authorization code and issues an Access Token and a Refresh Token.
The client can access the resources on the resource server using the issued Access Token.
When the Access Token expires, the client uses the Refresh Token to request a new Access Token from the authorization server.

Implicit Grant

Recommended to use
The most commonly used authentication method
Typically used when a user logs into a shopping mall (User Agent Application)

The user attempts to log in to the authentication server using the client. After the authentication server completes the login authentication, it issues an access token.
The authentication server returns a redirection response that includes the access token to the client. The access token is included in the URI fragment.
The client extracts the access token from the redirection response and attempts to access the resource on the resource server using the token. After the resource server verifies the validity of the access token with the authentication server, the client can access the requested resource.

Resource Owner Password Credentials Grant

Not recommended to use
Can be used in all types of applications
Typically used in API connections

The user submits their ID, password, and client information to the authentication server using the client. After the authentication server authenticates the login and client information, it issues an access token.
The client can access the resource server's resource using the issued access token.

Client Credentials Grant

Not recommended
The access token can be issued directly based on client authentication
Used to access application data, not user-related data

The client sends its client information (client ID and client secret) to the authorization server. If the client information is authenticated by the authorization server, an access token is issued.
The client can use the access token to access resources on the resource server.

Device Code Grant

Not recommended
Authentication is carried out using a separate device
Used when there is no web browser or limited input device (e.g., smart TV, game console)

The user starts the client application on the device with limited input. The client requests a device code, a user code, and a verification URL from the authorization server.
The authorization server returns a device code, a user code, and a verification URL to the client. The user goes to the verification URL on a different device (e.g., smartphone, computer) to enter the user code and complete the login.
The client sends the device code and client identifier to the authorization server and requests an access token.
After the user completes the login authentication on the verification URL, the authorization server issues an access token, and the client can use the access token to access resources on the resource server.

Refresh Token Grant

Access tokens are refreshed using a refresh token, and the original access token expires after a certain period.