Access Token/Refresh Token 저장 위치

발급 방법과 토큰 종류에 따라 사용처와 보안 요구 사항이 다르기 때문에 저장 위치를 생각해보고자 합니다.

발급 방법

발급 방법은 2가지가 있습니다.

• 구성원 계정으로 인증(OAuth): 개인별로 발급되며, 사용자가 로그인할 때 발급되고 로그아웃 시 만료됩니다.
• 서비스 계정으로 인증(JWT): 서버가 발급. 도메인별로 하나만 발급되며, 여러 사용자 요청에 공통으로 사용됩니다.

서비스 계정과 사용자 계정은 인증 방식이 다르고 목적도 다르기 때문에 각각의 Access Token을 따로 관리하고 저장해야 합니다. (두 가지 토큰은 다른 API 접근 권한 가짐.)

*Access Token은 사용자 정보를 담고 있는 토큰. api가 어떤 방식으로 발급된 토큰인지 구분 할 수 있습니다.

 

토큰의 종류

여기서는 Access Token과 Refresh Token만 보겠습니다.

• Access Token: 유효기간 짧음(1일 정도).
• Refresh Token: Access Token 갱신 토큰. 유효기간 상대적으로 김(90일 정도).

Refresh Token이 기본적으로 여러번 사용 가능하고 유효 기간이 더 길기 때문에 보안 요구사항이 더 높다고 볼 수 있습니다.

* 보안을 위해 Refresh Token을 1회용으로 사용하여 access Token 갱신 시 refresh Token도 같이 재발급 받거나, 아예 사용하지 않도록 하는 경우도 있습니다.

 

결론

각 저장소를 비교해 보고 Access Token과 Refresh Token의 저장소를 아래와 같이 선택했습니다. (JAVA 기반 웹 어플리케이션 기준으로)

정답이 아니며 애플리케이션 특성에 따라 선택할 수 있습니다. 

 

*저장소 상세 비교

https://sumni.tistory.com/391

저장소 비교

 

1. Access Token

1-1. 구성원 계정 (OAuth)

추천 저장소: 세션 (Session)

• 장점: 사용자 별로 세션을 관리하므로 보안이 높고, 서버에서 직접 관리하여 탈취 위험이 적습니다.
• 단점: 서버 메모리 사용량 증가와 세션 만료 시 정보 소실 위험이 있습니다. 웹기반이 아니면 사용 불가능.

1-2. 서비스 계정 (JWT): 공통으로 접근 할 수 있는 저장소.

추천 저장소: 서버의 정적 변수 (Static Variable)

• 장점: 서버 간 통신 시 빠른 접근이 가능하며, 여러 인스턴스 간 공유가 용이합니다.
  • *같은 서버를 쓰는 도메인이 여러 개일 때 정적 배열 형태로 관리 가능.
• 단점: 멀티스레딩 환경에서 데이터 경쟁 문제가 발생할 수 있으며 (동기화 기법이 필요), 애플리케이션 재시작 시 정보가 손실될 수 있습니다.
  • *멀티스레딩 환경에서 경쟁 문제 (단일 스레드면 사용자 요청 순차적으로 처리되어 성능이 안 좋음.)
  • *클라우드 환경이나 분산 시스템에서는 서버 인스턴스가 동적으로 생성되고 제거될 수 있기 때문에, 정적 변수가 초기화 될 수 있습니다.

 

추천 저장소: 메모리 캐시 (예: Redis)

• 장점: 메모리 내에서 빠른 데이터 접근을 제공하며, TTL(Time To Live) 설정으로 자동 만료된 데이터 관리가 용이하고, 여러 인스턴스 간 데이터 공유 및 장애 시 데이터 복구 기능을 지원합니다.
• 단점: 별도 설치 필요(스프링은 spring-boot-starter-data-redis 의존성 추가), 메모리 사용량이 증가하고 서버 재시작 시 데이터 소실(방지 or 복구 하는 방법 있음)될 수 있습니다. 또 메모리 캐시의 상태를 모니터링하고 관리하는 데 추가적인 오버헤드가 발생할 수 있습니다.

redis 사용 예시

import redis.clients.jedis.Jedis;
public class RedisExample {
    public static void main(String[] args) {
        // Redis 서버에 연결
        Jedis jedis = new Jedis("localhost", 6379); // 호스트와 포트 설정

        // 데이터 저장
        jedis.set("key", "value");
        System.out.println("Stored string in Redis: " + jedis.get("key"));

        // 데이터 조회
        String value = jedis.get("key");
        if (value != null) {
            System.out.println("Retrieved value: " + value);
        } else {
            System.out.println("Value not found in Redis");
        }

        // 데이터 삭제
        jedis.del("key");
        System.out.println("Deleted key from Redis");

        // 연결 종료
        jedis.close();
    }
}

 

 

2. Refresh Token

2-2. 구성원 계정 (OAuth)

추천 저장소: 브라우저의 HttpOnly 쿠키, Secure 쿠키

- 장점

• 사용자가 브라우저를 재시작해도 쿠키는 유지됩니다.
• HTTP Only Cookie: XSS 방지. Client에서 Javascript를 통한 쿠키 탈취문제를 예방
• Secure 접미사를 사용: HTTPS 가 아닌 통신에서는 쿠키를 전송하지 않습니다. HTTPS 프로토콜을 사용하여 데이터를 암호화하여 서버에 넘겨주도록 하여 탈취시에도 이용할 수 없도록 합니다.

- 단점

• 쿠키 크기 제한.

2-3. 서비스 계정 (JWT)

추천 저장소: 서버 측 데이터베이스

• 장점: 영구적으로 저장할 수 있으며, 데이터 백업 및 복원이 용이합니다.
• 단점: I/O 오버헤드로 인해 성능 저하가 발생할 수 있으며, 복잡한 쿼리가 필요할 수 있습니다.