One of the most commonly implemented feature in APIs. It is a process of confirming the user's identification, such as checking the user's ID and password during login.

Login process explained

  1. User account created
  2. User password is encrypted and saved in the database
  3. User types in ID and password during login
  4. Input password is encrypted and compared with the user's password stored in the database
  5. If they match, login successful
  6. Access token sent from the server to the client (user)
  7. This access token will be sent to the server as a part of the header of the user's future requests, so the user does not have to login repetitively

One-way hash function

One-way hash functions create a digest (an encrypted message) from an original string message, which cannot be decrypted from the digest form.
Examples are MD5, SHA-1, SHA-256, SHA-512

import hashlib

m = hashlib.sha256()

m.update(b"test password")

>>> '0b47c69b1033498d5f33f5f7d97bb6a3126134751629f4d0185c115db44c094e'

m = hashlib.sha256()

m.update(b"test password2")

>>> 'd34b32af5c7bc7f54153e2fdddf251550e7011e846b465e64207e8ccda4c1aeb'

As we can see from the example above, similar original messages result in completely different digests. This characteristic of one-way hashing is known as "avalance," and it makes hacking the original messages difficult.


It is a library that has implemented salting and key stretching solutions to any attaks on user information, namely rainbow table attack. Rainbow table is a table of various pre-computed hash values, and the attack compares these values with the target password and evaluates if there is a match.
An advantage of using bcrypt is that the values for salt, hash, and the number of stretches are stored together in the hash result. This feature simplifies database architecture as there is no need to store those values separately and retrieve them later for authentication comparison.

Typical Digest Structure


비밀번호와 임의로 생성한 문자열(Salt)를 합쳐서 해싱하여 이 해시값을 저장하는 방법.
이 경우에는 비교를 위해 해시값과 Salt값을 같이 저장해야 함.

Key stretching

단방향 해쉬값을 계산 한 후 그 해쉬값을 또 또 해쉬 하고, 또 이를 반복하는 것을 말한다.


For more security measures, HTTPS protocol is used, which is a more secure version of HTTP. Using SSL certificate, requests and responses are encrypted and cannot be easily hijacked mid-communication.


The function of specifying access rights and privileges to resources (eg whether a logged-in user has access to certain information).
Authorization is done via encrypted access tokens that get included in the request header as meta data.
The tokens are decrypted by the server to acquire user information.
Common way of creating an access token is by using JSON Web Tokens. User data is stored in encrypted JSON format.

JWT (JSON Web Tokens)

Authorization Steps
1. Authentication 절차를 통해 access token을 생성한다. access token에는 유저 정보를 확인할 수 있는 정보가 들어가 있어야 한다 (예를 들어 user id).
2. 유저가 request를 보낼때 access token을 첨부해서 보낸다.
3. 서버에서는 유저가 보낸 access token을 복호화 한다.
4. 복호화된 데이터를 통해 user id를 얻는다.
5. user id를 사용해서 database에서 해당 유저의 권한(permission)을 확인하다.
6. 유저가 충분한 권한을 가지고 있으면 해당 요청을 처리한다.
7. 유저가 권한을 가지고 있지 않으면 Unauthorized Response(401) 혹은 다른 에러 코드를 보낸다.

JWT Structure

Header contains information about token type and hash algorithm.
Header's content is encoded in Base64 and recorded in the first section of JWT.
For example,



Payload contains statements about the entity (typically, the user) and additional entity attributes, which are called claims. Also encoded in Base64.
For example,

	"sub": "12345678",
    "name": "John Doe",
    "admin": true


Signature is the only part of JWT that is actually encrypted. It is used to verify that the sender of the JWT is who it says it is and to ensure that the message wasn't changed along the way.
The signature is created by taking Base64-encoded header, payload, and a secret along with a hashing algorithm such as SHA256.
If you are to create a signature for a token, you would need to do the following:

	base64UrlEncode(header) + "." + 

Unlike digests produced using bcrypt, JWTs can be and should be reversed, as they are used to constantly check for authorization for each user.

Why Use Access Token VS ID and Password?

No heavy bcrypt call, just a simple hash

Client-side storage
Actual ID and password are not stored in the client side (ex-cookie).
Token is very server specific and cannot be reused in any other site, which provides more stable and secure means of authorization.

0개의 댓글