게임 계정 인증 및 토큰 갱신: OAuth 2.0과 Stateless JWT 보안 아키텍처

핵심 요약

대규모 동시접속 환경의 게임 백엔드에서는 중앙 세션 저장소의 병목을 방지하기 위해 비대칭키(RS256/Ed25519) 기반 Stateless JWT를 Access Token으로 사용하고 중앙 집중식 Redis 기반 Refresh Token Rotation(RTR)을 결합하여 보안성과 확장성을 동시에 확보합니다. 클라이언트는 플랫폼(Steam, Google, Apple) 인증을 OAuth 2.0 Authorization Code Flow with PKCE로 완결하며 게임 서버 인스턴스는 JWKS(JSON Web Key Set) 캐싱을 통해 중앙 DB 조회 없이 $O(1)$ 복잡도로 인증을 검증합니다.

게임 서버에서 왜 세션 대신 Stateless JWT를 사용할까?

전통적인 웹 애플리케이션에서는 RDBMS나 Redis 세션 저장소에 세션 ID를 조회하는 Stateful 방식을 흔히 사용합니다. 하지만 초당 수십만 건의 패킷과 API 요청이 분산 처리되는 게임 서버 환경(인증 서버, 매치메이커, 다수의 데디케이티드 존 서버)에서는 중앙 세션 조회 방식이 치명적인 성능 병목을 유발합니다.

Stateful 방식과 Stateless JWT 방식을 비교하면 다음과 같습니다.

비교 항목	Stateful 세션 방식	Stateless JWT (비대칭 서명)
검증 주체	중앙 세션 저장소 (Redis/DB)	각 게임 서버 인스턴스 (Local)
서버 확장성 (Scale-out)	세션 저장소 용량 및 I/O 대역폭 종속	완전 무상태성으로 무제한 수평 확장 가능
검증 오버헤드	네트워크 I/O 발생 (1~5ms 추가 지연)	CPU 서명 검증만 수행 ( $< 0.1\text{ms}$ )
토큰 즉시 무효화	세션 삭제로 즉각 반영 용이	만료 전까지 기본 무효화 불가 (블랙리스트 필요)
네트워크 페이로드	세션 ID만 전송하므로 매우 작음 ( $< 64\text{B}$ )	클레임 포함으로 상대적 큼 ( $500\text{B} \sim 1.5\text{KB}$ )

중앙 저장소 조회를 생략하면 요청당 네트워크 대기 시간은 줄어들 수 있습니다. 초당 요청 수가 $R$ 이고 요청당 줄어든 대기 시간이 $\Delta t$ 라면 $R\Delta t$ 는 초당 절약되는 누적 요청 대기 시간(대략 동시에 비워지는 요청 처리 슬롯 수)을 추정할 뿐, 처리량 증가량 자체를 뜻하지는 않습니다.

\text{Saved Request Time per Second} \approx R \times \Delta t_{\text{network\_IO}}

OAuth 2.0과 OpenID Connect 기반의 플랫폼 계정 연동

PC 및 모바일 게임은 독립 계정 시스템뿐만 아니라 Steam, Apple Game Center, Google Play Games, Epic Games 등 외부 플랫폼 계정 연동이 필수적입니다. 이때 클라이언트 변조 및 중간자 공격(MITM)을 방지하기 위해 PKCE(Proof Key for Code Exchange, RFC 7636)가 적용된 OAuth 2.0 Authorization Code Flow를 사용합니다.

sequenceDiagram
    autonumber
    actor Player as 게임 클라이언트
    participant IdP as 인증 제공자 (Google/Steam/Apple)
    participant AuthServer as 게임 인증 서버 (Auth Service)
    participant Redis as Token DB (Redis Cluster)
    participant GameServer as 데디케이티드 게임 서버

    Player->>Player: Code Verifier & Code Challenge 생성 (S256)
    Player->>IdP: 로그인 요청 (Code Challenge 전달)
    IdP-->>Player: Authorization Code 반환
    Player->>AuthServer: 토큰 교환 요청 (Auth Code + Code Verifier)
    AuthServer->>IdP: 토큰 유효성 검증 및 서드파티 ID 획득
    AuthServer->>Redis: Refresh Token 및 패밀리 메타데이터 저장
    AuthServer-->>Player: Access Token (Stateless JWT) + Refresh Token 발급
    Player->>GameServer: 패킷 전송 시 Access Token 첨부
    GameServer->>GameServer: 캐시된 Public Key로 로컬 서명 검증

OAuth 2.0 및 소셜 플랫폼 로그인 연동 아키텍처 흐름도

플랫폼 연동 단계별 절차

Code Verifier 생성: 클라이언트는 고유한 무작위 문자열(Code Verifier)을 생성하고 이를 SHA-256으로 해싱하여 Code Challenge를 만듭니다.
인가 코드 발급: 외부 IdP 웹뷰 또는 네이티브 SDK를 통해 사용자가 로그인하면 IdP로부터 일회용 Authorization Code를 수신합니다.
게임 인증 서버 교환: 클라이언트는 Authorization Code와 원본 Code Verifier를 게임 인증 서버로 전송합니다. 인증 서버는 이를 플랫폼 백엔드와 검증하여 서드파티 고유 유저 식별자(UID)를 확보합니다.
게임 전용 토큰 발급: 인증 서버는 자체 비밀키(Private Key)로 서명한 단기 Access Token과 암호학적으로 안전한 무작위 난수로 구성된 Refresh Token을 생성하여 클라이언트에 응답합니다.

Stateless JWT 발급 및 비대칭 서명 검증 아키텍처

게임 백엔드에서는 대칭키(HS256) 방식 대신 비대칭키(RS256 또는 Ed25519) 방식을 권장합니다. 대칭키 방식은 모든 게임 서버 노드가 동일한 비밀키를 공유해야 하므로 서버 노드 하나가 탈취당했을 때 전체 인증 체계가 무너지는 치명적인 결함이 있습니다.

비대칭키 구조에서는 오직 인증 서버만 개인키(Private Key)를 보유하며 분산된 모든 게임 서버와 게이트웨이는 공개키(Public Key)만 내려받아 로컬에서 검증합니다.

Go 언어 기반 JWT 비대칭 서명 및 로컬 검증 예제

package auth

import (
	"crypto/rsa"
	"errors"
	"time"

	"github.com/golang-jwt/jwt/v5"
)

type GameClaims struct {
	AccountID   string   `json:"sub"`
	CharacterID string   `json:"cid"`
	Roles       []string `json:"roles"`
	TokenFamily string   `json:"fid"`
	jwt.RegisteredClaims
}

// GenerateAccessToken: 인증 서버에서 개인키(RS256)로 발급
func GenerateAccessToken(accountID, characterID, tokenFamily string, signKey *rsa.PrivateKey) (string, error) {
	claims := GameClaims{
		AccountID:   accountID,
		CharacterID: characterID,
		Roles:       []string{"player"},
		TokenFamily: tokenFamily,
		RegisteredClaims: jwt.RegisteredClaims{
			ExpiresAt: jwt.NewNumericDate(time.Now().Add(15 * time.Minute)), // 15분 만료
			IssuedAt:  jwt.NewNumericDate(time.Now()),
			Issuer:    "https://auth.game.example.com",
			Audience:  jwt.ClaimStrings{"game-api-cluster"},
		},
	}

	token := jwt.NewWithClaims(jwt.SigningMethodRS256, claims)
	return token.SignedString(signKey)
}

// ValidateTokenLocally: 분산 게임 서버에서 공개키로 로컬 검증
func ValidateTokenLocally(tokenString string, verifyKey *rsa.PublicKey) (*GameClaims, error) {
	token, err := jwt.ParseWithClaims(tokenString, &GameClaims{}, func(token *jwt.Token) (interface{}, error) {
		if _, ok := token.Method.(*jwt.SigningMethodRSA); !ok {
			return nil, errors.New("unexpected signing method")
		}
		return verifyKey, nil
	})

	if err != nil || !token.Valid {
		return nil, errors.New("invalid or expired token")
	}

	claims, ok := token.Claims.(*GameClaims)
	if !ok {
		return nil, errors.New("invalid token claims")
	}

	return claims, nil
}

리프레시 토큰 보안: Refresh Token Rotation (RTR)

Stateless Access Token은 만료 시간을 짧게(5분~15분) 유지하지만 장기 세션을 유지하기 위한 Refresh Token이 유출될 경우 심각한 보안 위협이 됩니다. 이를 완화하기 위한 표준 솔루션이 Refresh Token Rotation (RTR)입니다.

클라이언트가 Refresh Token을 사용해 새 Access Token을 요청할 때마다 기존 Refresh Token을 즉시 폐기하고 새로운 Refresh Token을 발급합니다.

Refresh Token Rotation과 비정상 재사용 탐지 메커니즘

RTR 및 재사용 탐지(Replay Attack Detection) 흐름

토큰 패밀리(Token Family) 부여: 최초 로그인 시 고유한 Family ID (UUID)를 생성하여 Refresh Token 메타데이터에 바인딩합니다.
1회용 토큰 교체: 클라이언트가 토큰 갱신을 요청하면 현재 활성 상태인 RT_1을 즉시 삭제 처리하고 RT_2를 발급합니다.
재사용 공격 감지: 만약 공격자가 탈취한 이전 토큰 RT_1을 다시 사용하려고 시도하면 인증 서버는 이를 침해 사고로 판단합니다.
패밀리 전체 무효화: 동일 패밀리 ID에 속한 모든 Refresh Token을 Redis에서 즉시 삭제하여 공격자와 피해자 모두 세션을 강제 종료시킵니다.

-- Redis Lua Script: Atomic Refresh Token Rotation & Replay Detection
local account_id = KEYS[1]
local incoming_token = ARGV[1]
local new_token = ARGV[2]
local ttl = tonumber(ARGV[3])

local current_token = redis.call('GET', 'rt:' .. account_id)

if not current_token then
    -- 이미 만료되었거나 침해 감지로 삭제된 상태
    return -1
end

if current_token ~= incoming_token then
    -- 이미 회전되어 무효화된 과거 토큰으로 접근 -> 탈취 감지 (패밀리 전체 제거)
    redis.call('DEL', 'rt:' .. account_id)
    redis.call('SET', 'compromised:' .. account_id, '1', 'EX', 86400)
    return -2
end

-- 정상 갱신: 새 토큰으로 원자적 교체
redis.call('SET', 'rt:' .. account_id, new_token, 'EX', ttl)
return 1

긴급 세션 차단과 블랙리스트 무효화 전략

Stateless JWT의 태생적 한계는 한 번 발급된 토큰은 만료 시간(exp) 전까지 자체적으로 취소할 수 없다는 점입니다. 핵 사용자 제재나 계정 도용 시 실시간 접속 차단이 필수적인 게임 환경에서는 보완 전략이 필요합니다.

하이브리드 무효화 아키텍처

최소 수명 전략: Access Token의 수명을 최대 5분~10분으로 짧게 설정하여 탈취 피해 시간을 최소화합니다.
Redis Pub/Sub 기반 블랙리스트 브로드캐스팅: 관리자 차단 발생 시 Token ID (JTI) 또는 AccountID를 Redis Pub/Sub 채널로 발행하여 모든 활성 게임 서버의 로컬 인메모리 LRU 캐시에 블랙리스트로 등록합니다.
Bloom Filter 활용: 대규모 사용자 차단 목록이 존재할 경우 게임 서버 로컬 메모리에 Bloom Filter를 구축하여 불필요한 Redis I/O를 원천 차단합니다.

자주 묻는 질문 (FAQ)

Q1. 실시간 TCP/UDP 게임 플레이 도중 Access Token이 만료되면 접속이 끊어지나요?

아닙니다. 실시간 소켓 연결은 세션 핸드셰이크 단계(인증 단계)에서만 JWT의 유효성을 검증하고 연결이 성공한 후에는 소켓 연결 자체의 생명주기를 유지합니다. 다만 인게임 상점 구매나 랭킹 등록 등 중요한 비동기 HTTP/gRPC API를 호출할 때는 유효한 Access Token이 요구되므로 게임 클라이언트는 백그라운드 타이머를 통해 만료 1~2분 전 사전 갱신(Proactive Token Refresh)을 수행해야 합니다.

Q2. 게임 클라이언트에서 JWT와 Refresh Token은 어디에 안전하게 저장해야 하나요?

모바일 환경(iOS/Android)의 경우 OS 레벨의 암호화 저장소인 iOS Keychain 및 Android EncryptedSharedPreferences (Keystore)를 사용해야 합니다. PC/스팀 빌드의 경우 Windows Data Protection API(DPAPI)를 활용해 암호화한 후 로컬에 저장하여 메모리 덤프나 파일 복사를 통한 토큰 탈취를 방어해야 합니다.

Q3. 비대칭 서명 알고리즘으로 RS256과 Ed25519 중 무엇을 선택해야 할까요?

성능과 대역폭이 극도로 중요한 대규모 게임 서버 환경에서는 Ed25519 (EdDSA)가 가장 이상적입니다. RSA-2048(RS256) 대비 키 길이가 훨씬 짧고 서명 생성 및 검증 연산 속도가 수 배 빠릅니다. 단, 사용하는 백엔드 라이브러리 및 게이트웨이(예: NGINX, Envoy, Kong)의 호환성에 따라 RS256이 여전히 널리 표준으로 사용됩니다.

요약 및 결론

게임 백엔드 인증 아키텍처의 핵심은 검증의 분산화(Stateless)와 갱신 통제의 중앙화(Stateful)의 균형에 있습니다.

외부 계정 연동은 OAuth 2.0 with PKCE를 적용하여 클라이언트 위변조 위험을 원천 차단합니다.
잦은 API 검증은 비대칭키 기반 Stateless JWT를 활용하여 중앙 세션 저장소 병목 없이 분산 게임 서버에서 직접 처리합니다.
장기 인증 관리는 Refresh Token Rotation (RTR)과 재사용 감지 로직을 도입해 토큰 탈취 공격을 자동으로 격리합니다.
긴급 차단이 필요한 경우 Pub/Sub 기반의 분산 인메모리 블랙리스트를 하이브리드로 결합하여 안전하고 유연한 게임 백엔드 보안을 완성할 수 있습니다.