jwt 클라이언트, 서버, 디비 별 관점과 관리방법

Access token과 refresh token을 사용하는 과정은 일반적으로 다음과 같은 순서로 진행됩니다.

클라이언트 관점
로그인 요청: 사용자가 로그인 폼에 정보를 입력하고 서버로 로그인 요청을 보냅니다.

 

POST /login
Content-Type: application/json

{
  "username": "heajun_kim",
  "password": "your_password"
}

토큰 수신: 서버로부터 access token과 refresh token을 받습니다.

{
  "accessToken": "generated_access_token",
  "refreshToken": "generated_refresh_token"
}

Access Token 이용: 클라이언트는 보호된 리소스에 접근할 때 access token을 사용합니다.

GET /protected-resource
Authorization: Bearer generated_access_token

Access Token 만료: access token이 만료되면, 클라이언트는 refresh token을 사용하여 새로운 access token을 요청합니다.

POST /token/refresh
Content-Type: application/json

{
  "refreshToken": "generated_refresh_token"
}

새로운 토큰 수신: 서버로부터 새로 갱신된 access token을 받습니다.

{
  "accessToken": "new_generated_access_token",
  "refreshToken": "new_generated_refresh_token"
}

서버 관점
로그인 처리: 서버는 로그인 요청을 받아 사용자 인증을 수행합니다.
토큰 생성: 인증이 성공하면, 서버는 access token과 refresh token을 생성합니다.
토큰 저장: 생성된 refresh token은 데이터베이스에 저장하고, access token은 응답으로 클라이언트에 전송합니다.
토큰 인증: 보호된 리소스에 대한 요청이 들어오면, 서버는 수신된 access token을 검증합니다.
토큰 갱신: access token이 만료되었을 때, 서버는 수신된 refresh token을 검증하고 새 access token을 생성 및 반환합니다. 새로운 refresh token도 갱신하여 반환할 수 있습니다.
디비 관점
사용자 테이블: 사용자 데이터를 관리합니다.
토큰 테이블: refresh token과 관련된 정보를 저장합니다. (예: 사용자 ID, 토큰 값, 만료 시간 등)
대략적인 순서와 흐름은 다음과 같습니다.

클라이언트: 로그인 요청 → 서버: 사용자 인증 → 서버: access token 및 refresh token 생성 → 서버: refresh token 저장 (디비) → 클라이언트: access token 및 refresh token 수신
클라이언트: 보호된 자원에 대한 요청 → 서버: access token 검증
클라이언트: access token 만료 시 refresh token으로 토큰 갱신 요청 → 서버: refresh token 검증 → 서버: 새로운 access token 및 refresh token 생성 → 서버: 디비에 새로운 refresh token 저장 → 클라이언트: 새로운 access token 및 refresh token 수신
이 과정은 보안과 효율성을 높여주며, refresh token을 통해 클라이언트가 다시 로그인하지 않고도 오래 지속되는 세션을 유지할 수 있도록 합니다.

 

 

 

1. 별도의 토큰 테이블 사용
장점:
토큰 관련 데이터만을 관리하여 테이블의 역할이 명확해짐.
사용자와 토큰의 관계를 쉽게 확장할 수 있음 (예: 한 사용자가 여러 개의 토큰을 가질 수 있음).
필요시 토큰 데이터만 별도로 삭제 또는 관리하기 용이.
단점:
테이블이 추가되어 DB 구조가 복잡해질 수 있음.
예시:

CREATE TABLE refresh_tokens (
  id SERIAL PRIMARY KEY,
  user_id INT REFERENCES users(id),
  token VARCHAR(255) NOT NULL,
  expires_at TIMESTAMP NOT NULL
);

 

2. 사용자 테이블에 컬럼 추가
장점:
테이블 수가 적어져서 구조가 단순해짐.
선택적 추가 정보가 적어 유지 보수가 쉬울 수 있음.
단점:
토큰과 사용자 데이터가 강하게 결합되어 데이터 관리가 어려워질 수 있음.
하나의 사용자에 대해서 하나의 리프레시 토큰만 허용할 경우 유리.
예시:

ALTER TABLE users ADD COLUMN refresh_token VARCHAR(255);
ALTER TABLE users ADD COLUMN refresh_token_expires_at TIMESTAMP;