[Kotlin + Spring] MSA 환경에서 토큰 기반 인증 구현하기 (RTR, JWT vs UUID, Redis)

🧐 MSA 환경에서 로그인 시스템은 어떻게 구현할까?

마이크로서비스 아키텍처

마이크로서비스 아키텍처(MSA)는 서비스 간 독립성을 유지하면서도 유기적으로 연결된 분산 시스템을 구축하는 방식이다. 하지만 여러 개의 독립적인 서비스가 존재하는 MSA 환경에서는 "사용자 인증을 어떻게 관리할 것인가?" 하는 문제가 발생한다.

기존 모놀리식 아키텍처(Monolithic Architecture)에서는 단일 서버가 세션을 관리하면 되었지만, MSA 환경에서는 인증에 대해 어떻게 처리해야 할지에 대한 문제가 생긴다. 각 서비스가 개별적으로 인증을 처리해야 할까? 그렇다면 서비스마다 로그인 로직을 구현해야 할까? 아니면 중앙 집중식 인증 시스템을 구축해야 할까?

 

우리가 기존에 쓰는 로그인 구현 방식은 다음과 같이 크게 세 가지로 분류할 수 있다.

1. 세션 기반 인증 시스템
2. 토큰 기반 인증 시스템
3. OAuth 2.0, 제 3자 로그인, 소셜 로그인 시스템

위의 로그인 구현 방식 중 세션 기반과 토큰 기반을 비교하여 MSA 환경으로 들어서면 생기는 문제점과 해결방안에 대해 알아보겠다.

---

1️⃣ 세션 기반 인증 시스템

세션 기반 인증의 동작은 위와 같다.

• 사용자가 로그인하면 서버에서 세션을 생성하고, 세션 ID를 쿠키에 저장하여 클라이언트에게 반환
• 이후 요청에서 클라이언트가 쿠키를 함께 전송하면, 서버에서 해당 세션 정보를 조회하여 인증 처리

그렇다면 MSA 환경에서는 어떻게 동작해야 할까?

MSA 환경에서 Session 기반 인증 시스템 문제점

Session 기반 인증 서버에서 세션은 DB에 저장하기에 MSA환경으로 들어서게 되면 Client가 Session ID를 받은 서버가 아닌 다른 서버에 접근할 때 Session Id를 인증할 수가 없는 문제점이 발생한다.

즉 세션을 유지하려면 사용자는 같은 서버로 접근해야 한다.

이에 대한 해결 방안으로, 모든 서버가 세션 데이터를 공유할 수 있도록 중앙 DB를 활용하는 방법이 있다.

 

📢 문제점

1. 중앙 집중형 DB의 문제점

DB가 단일 장애점(Single Point of Failure, SPOF)이 될 위험이 있으며, 장애 발생 시 모든 서버가 영향을 받을 수 있다.

 

2. DB 과부하

여러 서버가 하나의 DB에 동시 접근하게 되므로 트래픽 증가에 따른 성능 저하와 동시성 문제가 발생할 가능성이 높다.

---

2️⃣ 토큰 기반 인증 시스템

토큰 기반 인증 시스템은 MSA 환경에 적합한 특징을 지니고 있다.

토큰 기반 인증 시스템의 동작 방식은 위와 같다.

• 로그인 시 Access Token과 Refresh Token을 발급
• 클라이언트는 이후 요청 시 Authorization 헤더에 Access Token을 포함하여 전송
• 서버는 토큰을 검증하여 인증 처리 (DB 조회 없이도 인증 가능)
• Access Token이 만료되면 Refresh Token을 이용해 새로운 Access Token을 발급

 

JWT는 MSA 환경에서 어떻게 동작할까?

JWT의 특징 중 하나는 바로 Stateless 하다는 특징이다.

JWT는 토큰 자체에 사용자 정보(Claims)를 포함하기 때문에 별도 서버 상태(State) 유지가 필요 없다.

즉, 어떤 서버에서 요청을 받아도 동일한 인증 처리 가능하여 수평 확장에 최적화되어 있다.

 

위와 그림과 같이, Gateway에서 Access token에 대한 검증 로직만 수행하고, Client는 Auth 서버로부터 Access token을 발급받아서 해당 토큰으로 다른 서버에 접근할 수 있다.

 

📢 문제점

1. Access 토큰 탈취 위험

클라이언트는 유효한 Access Token만 있으면 어느 서버든 쉽게 접근할 수 있다. 그렇기 때문에 토큰을 탈취당하면 모든 서버에 대한 접근이 뚫리게 된다. 또한 Access Token은 Stateless 하기 때문에 강제로 만료시키기도 어렵다.

 

2.  Refresh 토큰 탈취 위험

만약 Refresh 토큰이 Stateless 하게 설정이 되어있다면, 탈취되었을 때, 유효한 기간 동안 계속해서 Access Token을 발급받아 여러 서버에 접근이 가능해진다.

 

MSA환경에서 JWT를 적용하기 위해 이러한 문제점을 해결하기 위해 적용할 수 있는 방법들을 다루고자 한다.

---

✅ MSA 환경에서 JWT 문제점 해결하기

1️⃣ RTR 도입하기

RTR(Refresh Token Rotation, 리프레시 토큰 순환)란?

Refresh Token을 재사용하지 않고, 한 번 사용할 때마다 새로운 Refresh Token을 발급하는 방식이다.
즉, 매번 Access Token을 갱신할 때 새로운 Refresh Token도 함께 발급되며, 기존 Refresh Token은 폐기된다.

 

RTR을 도입하는 가장 큰 이유는 Refresh Token 탈취 방지 및 보안 강화이다.

MSA 환경에서 Refresh Token이 유출되면, 공격자가 계속 Access Token을 재발급받을 수 있다. 그렇기 때문에 Refresh Token의 만료기간이 길면 길수록, 보안에 취약해진다.

RTR의 동작방식은 기존의 JWT 방식과 크게 다른 점이 없다.

중요한 부분은 Access Token을 발급받을 때 Refresh Token도 새롭게 발급받고 기존의 Refresh Token은 폐기한다는 점이다. 이렇게 RTR을 도입함으로써 Refresh Token 탈취 및 재사용 공격을 효과적으로 방어할 수 있다.

---

2️⃣ UUID vs JWT Refresh Token

Refresh Token을 구현하는 방식에는 크게 두 가지가 있다.

JWT 방식과 UUID 방식 도식화

---

🔹1. JWT

JWT는 Json Web Token의 약자이다.

즉, 사용자에 대한 정보를 payload안에 json의 형태로 집어넣어서 관리한다.

클레임 내부에 유저 정보(sub). 만료 시간(exp)등을 포함하여 Stateless 한 방식으로 동작하도록 구성하는 것이다.

 

이때, 서버는 Refresh Token의 payload를 검증만 하면 되므로 별도의 저장소가 필요하지 않다.

위의 방식으로 관리하게 된다면, 단순히 클라이언트에게 Refresh Token을 발급하게 되었을 때, 유효기간이 만료될 때까지 계속해서 사용이 가능하다.  또한 Stateless한 방식을 지니고 있기에 서버에 부하를 주지 않으며, MSA 환경에서 확장성이 뛰어나다.

 

하지만, 보안상의 문제로는 취약하다. 

Refresh Token이 탈취되면 만료될 때까지 계속 사용가능하며, 클라이언트가 로그아웃을 시도했을 때 Refresh Token을 무력화시킬 수 없다. 또한 위와 같이 구현하게 되면 RTR을 적용하기가 어렵게 된다.

---

🔹2. UUID

그래서 조금 더 보안성의 부분에 신경을 쓴 부분이 바로 UUID를 활용하는 방식이다.

UUID: 전역에서 고유한 값을 생성하는 식별자이다. 예측이 어렵고 암호학적으로 안전한 난수를 생성 가능하다.

기존의 JWT의 방식과는 다르게 DB에 Refresh Token을 저장하고 Refresh Token이 필요할 때마다 DB에서 해당 Token을 조회해 유효성을 검증하는 방식이다. 

Refresh Token을 서버에서 관리하므로 보안성이 높다. 또한 Access Token을 발급받을 때 RTR을 적용함으로써 Refresh Token을 재발급하고 이전의 Refresh Token에 대해서는 DB에서 삭제함으로써 무력화시킬 수 있다. 마찬가지로 클라이언트에서 로그아웃을 시도했을 때 해당 Refresh Token을 삭제할 수 있다.

 

다만 이렇게 보안성이 높아진 대신 기존 JWT의 Stateless의 특징은 잃어버리고 Redis와 같은 별도의 저장소가 필요하다.

또한 MSA 환경에서 위와 같은 구조로 구현하려면 Auth에 대한 서버를 별도로 두어 진행해야 한다.

 

그럼에도 불구하고 UUID로 Refresh Token을 구현하는 방식은 기존의 JWT 방식의 보안적인 단점을 보완할 수 있는 방식이며 RTR을 적용할 수 있는 방식이다.

---

🧐UUID 방식, Redis에 저장할 때 Key 전략?

Redis에 저장할 때, Key전략을 어떻게 가져갈 것인지에 대한 고민을 해보았다.

이를 통해 일관된 키 패턴을 사용하여 관리 및 조회를 쉽게 하는 전략에 달성하고자 하였다.

RedisConfig.kt

@Bean
fun redisTemplate(redisConnectionFactory: RedisConnectionFactory): RedisTemplate<String, Any> {
    return RedisTemplate<String, Any>().apply {
        connectionFactory = redisConnectionFactory
        keySerializer = StringRedisSerializer()
        hashKeySerializer = StringRedisSerializer(
        
        valueSerializer = GenericJackson2JsonRedisSerializer()
        hashValueSerializer = GenericJackson2JsonRedisSerializer()
    }
}

 

우선, UUID로 저장하기 위해 HashSet으로 다음과 같이 데이터를 관리하고자 하였다.

(이때, RefreshToken은 UUID 기반으로 생성되는 문자열이다.)

Key	Filed	Value
"RT::${refreshToken}-v1"	refreshToken	userId

• Key  = "RT::${refreshToken}-v1"
  • RT: Refresh Token을 저장하는 Key임을 명확하게 나타내기 위해 Prefix(RT::)를 추가하였다.
  • ${refreshToken}: 각 Refresh Token이 고유한 값을 가지도록 UUID를 Key에 포함하였다.
  • v1: 버전 정보를 포함하여 향후 Refresh Token 로직을 변경할 때 쉽게 관리 가능하도록 하고, 버전 업할 때 한 번에 evict 할 수 있도록 하였다.
    • 예: DEL RT::*-v1 → v1 Refresh Token 전체 삭제
• Filed = refreshToken
  • refreshToken: 고값을 Filed에 넣음으로써 value를 찾고자 하였다.
    (수정필요 : 굳이 Filed값은 필요 없고 Key-Value형식으로 구현해도 좋아 보인다.)
• Value = userId
  • value에 userId를 집어넣어 추후에 유효성 검사를 할 때 userId를 꺼내어 비교할 수 있도록 하였다.

 

TokenService.kt

fun generateRefreshToken(userId: Long): String {
    val expiryDate = Date(Date().time + jwtProperties.refreshTokenExpiration)
    val refreshToken = UUID.randomUUID().toString()
    val key = "RT::${refreshToken}-v1"

    refreshTokenRepository.saveHash(key, refreshToken, userId, expiryDate.time);

    return refreshToken
}

위와 같이 Key, Filed, Value를 순서대로 redis에 저장함으로써 refreshToken을 관리할 수 있다.

또한 Redis의 ttl을 이용하여 유효기간 또한 설정할 수 있다.

---

🚨토큰 기반 인증 방식 보안성 강화하는 다른 방식들

토큰 기반 인증은 MSA 환경에서 확장성과 성능 면에서 뛰어난 장점을 제공하지만, 그럼에도 불구하고 여전히 보안에 취약한 부분들이 존재한다.

 

특히 Refresh Token이 탈취될 경우 공격자가 유효한 Access Token을 무한정 재발급받을 수 있기 때문에, 이를 방지하기 위한 추가적인 보안 조치가 필요하다.

 

위에서 다룬 RTR 방식, Redis 기반 저장 방식 이외에도, 다양한 보안 강화 기법을 적용하여 보다 안전한 인증 시스템을 구축할 수 있다.

 

1. IP 및 디바이스 정보를 활용한 Refresh Token 검증

• Refresh Token을 검증할 때, 사용자의 IP 주소나 User-Agent(브라우저, 디바이스 정보)를 함께 저장하고 비교하여 보안을 강화할 수 있다.
• 만약 Refresh Token 요청 시 기존의 정보와 다르면, 추가적인 인증(OTP, 이메일 인증)을 요구

2. JWT 방식에서 AccessToken와 RefreshToken의 Secret Key 다르게 설정

• Access Token와 Refresh Token의 Secret Key를 분리하여 관리하여 보안성 강화
• Refresh Token의 Secret Key는 Access Token의 Secret Key를 한 번 더 인코딩해서 생성하여,
  Access Token이 유출되더라도 Refresh Token 검증을 강화할 수 있도록 설계