Access Token과 Refresh Token

1. JWT로그인 동작 흐름

Access Token과 Refresh Token은 JWT형식으로 이루어진 토큰으로 로그인 성공시 서버에서 발급해 줍니다. 두 토큰은 둘다 JWT형식으로 생성되어 있지만, 사용하는 목적이나 , 유효시간 등 많은 부분에서 차이를 보입니다.

  1. 사용자가 로그인 요청 → 서버가 사용자 검증

  2. 서버는 Access Token과 Refresh Token을 발급

  3. 클라이언트는 API 호출 시 Access Token을 Authorization: Bearer <token> 헤더로 전달

  4. Access Token이 만료되면 클라이언트는 Refresh Token을 서버에 제출

  5. 서버는 Refresh Token을 검증 후 새 Access Token 발급

  6. Refresh Token까지 만료되면 사용자는 다시 로그인 필요

2. Access Token

클라이언트가 서버의 자원에 접근(Access)할 수 있는 권한이 있음을 증명하기 위한 토큰입니다. 클라이언트에서 서버로 API요청시 Authorization: Bearer <access token> 형식으로 토큰을 전달합니다.

이 토큰은 보통 브라우저의 메모리에 보관됩니다.

* AccessToken을 Cookie에 저장 및 관리하지 않는 이유

  1. API유연성문제

    1. SPA 환경에서는 클라이언트가 여러 다른 서버(A 서버, B 서버)에 요청을 보내야 할 때가 많다.

    2. 쿠키는 특정 도메인(localhost:8081)과 경로(/auth)에 종속되며 해당경로로 요청시 자동으로 첨부된다.

    3. 단, 지정한 도메인이 아닌 다른 서버로 토큰을 보내야 하는 경우 토큰이 자동으로 전달되지 않는다.

    4. 클라이언트가 js로 토큰을 가져와 헤더에 넣는 방식이 훨씬 유연

  2. CORS 설정문제

    1. 브라우저의 보안정책으로 인해, 서로다른 Orign간에는 쿠키를 자동으로 보내지 못하도록 설정되어 있다.

    2. 만일, 서로다른 Orign간에 쿠키허용을 위해서는 프런트에서는 요청 headr에 credentials: incldue 설정을하고, 백엔드에서는 CORS설정에서 Access-Control-Allow-Credentials: true 를 해주어야한다.

  3. 토큰 만료처리의 어려움

    1. httpOnly 쿠키는 자바스크립트로 삭제할 수 없기 때문에, 로그아웃 시 서버에 별도의 API 요청을 보내 쿠키를 만료시켜야 한다.

    2. 추가로 남은 만료시간을 확인하여 미리 리프레시토큰으로 갱신요청을 하는 로직을 구현하기 어렵다.

    3. 즉, 프론트의 모든 요청에 대한 제어는 전부 백엔드 서버에 주어지게 된다.

3. Refresh Token

Refresh Token은 유효시간이 짧은 Access Token을 새롭게 갱신하기 위한 용도의 토큰입니다. Refresh Token은 보통 브라우저의 Cookie와 서버측의 DB에 저장합니다.

Refresh Token은Access Token보다는 훨씬 긴 유효시간(주~달단위)을 가지고 있습니다.

4. 비교

구분
Access Token
Refresh Token

정의

API 요청 인증용 JWT

Access Token 재발급용 JWT

수명

짧음 (분 단위)

김 (일/주 단위)

저장 위치

클라이언트

서버(DB/Redis) 권장

목적

사용자 인증

Access Token 갱신

보안 위험

유출되면 API 요청 가능

유출되면 Access Token 무제한 발급 가능

PreviousJWTNextOauth2

Last updated