Skip to content
스토브
마지막 업데이트

실제 적용 흐름이 궁금하신가요?

이용 시나리오 / 로그인하기

인증(토큰·검증)

이해하기


스토브 인증은 게임 클라이언트·게임 서버·웹 서비스가 스토브 플랫폼의 이용자 정보를 안전하게 활용할 수 있도록 신원을 증명하는 절차예요. 인증을 연동하면 자체 회원 시스템을 구축하지 않고도 스토브 계정으로 로그인한 이용자의 인증 정보를 받아 게임 진입, API 호출, 결제, 제재 처리 등 인증이 필요한 모든 서비스에 활용할 수 있어요.

인증의 구성 요소

스토브 인증은 인증 주체에 따라 크게 두 가지 경로로 동작해요.

경로 인증 주체 사용 플랫폼 발급 토큰
이용자 인증 로그인한 개별 이용자 Mobile SDK, PC SDK, Web User Access Token, Refresh Token
서버 인증 게임 서버 (시스템) Server API Access Token

두 인증 경로 이해하기
ㆍ 이용자 인증: SDK·웹 모듈이 스토브 로그인을 처리해 User Access Token을 발급해요.
ㆍ 서버 인증: 게임 서버가 client_id/client_secret로 API Access Token을 발급받아 API 호출에 사용해요.
ㆍ 두 토큰은 역할이 달라 서로 대체할 수 없어요. 게임 서버는 이용자 토큰을 검증할 때 본인의 API Access Token을 함께 사용해요.

플랫폼별 인증 동선

게임이 출시되는 플랫폼(Mobile/PC/Web/Server)에 따라 인증 동선과 사용하는 도구가 달라요.
자사 게임의 출시 형태에 맞춰 필요한 영역만 연동하면 돼요.

플랫폼 연동 도구 획득 정보 주요 용도
Mobile Mobile SDK (Android/iOS/Unity/Unreal) User Access Token, 회원 식별자
(guid 또는 member_no)
모바일 게임 로그인 및 게임 서버 인증
PC PC SDK (PCSDK3) + 스토브 PC 클라이언트 User Access Token, 회원 식별자
(guid 또는 member_no)
PC 게임 실행 인증 및 게임 서버 인증
Web 스토브 Web 인증
(GNB 방식 또는 로그인 URL 방식)
SUAT
(Cookie 기반 Web Access Token)
게임 공식 홈페이지·이벤트 페이지 로그인 연동
Server 스토브 Platform API
(Server-to-Server)
API Access Token 이용자 토큰 유효성 검증, 제재 조회,
회원 정보 조회 등 백엔드 API 호출

플랫폼 연동 시 참고
ㆍ 멀티 플랫폼 게임은 Mobile + PC + Server 등 필요한 영역을 함께 연동해요.
ㆍ 게임 서버가 스토브 API를 호출하는 흐름이 있으면 플랫폼과 무관하게 Server 인증이 반드시 필요해요.

토큰의 종류와 역할

스토브에서 발급되는 토큰은 크게 세 가지로, 역할과 만료 시간이 각각 달라요.

Token Type 획득방법 역할(Role) 유효(Valid)
이용자 액세스 토큰
(User Access Token)
SDK 이용자 로그인 성공 시 발급. 이용자 인증 및 권한 증명에 사용.
보안상 유효 기간이 짧아 6시간만 유효.
6시간
(21600000ms)
리프레시 토큰
(Refresh Token)
이용자 액세스 토큰 만료 시 재발급용.
일정 기간 별도 인증 없이 액세스 토큰 갱신 가능.
SDK 내부 자동 갱신. 별도로 이 토큰을 직접 사용하지 않도록 주의.
720시간
(30일)
플랫폼 API 액세스 토큰
(API Access Token)
API 스토브 제공 API 사용 시 인증 수단으로 사용.
유효 기간이 길며, 만료 후 재발급 필요.
720시간
(30일)

토큰 사용 정책

토큰의 종류와 무관하게 모든 환경에서 공통으로 지켜야 하는 사용 원칙이에요.

원칙 설명
User Access Token은 캐싱 금지 발급 후 6시간 동안만 유효. 이용자의 재로그인·새로고침·로그아웃 등으로 변경 가능.
반드시 필요한 시점마다 SDK를 통해 실시간 조회.
자동 갱신은 SDK가 처리 SDK는 만료 시간의 80% 시점에 Refresh Token으로 자동 갱신.
게임 코드에서 Refresh Token을 직접 다루지 않음.
API Access Token은 서버에서만 관리 30일 유효한 서버 간 인증용. 클라이언트·외부 시스템·로그에 노출 금지.
expires_in을 저장해 만료 전 갱신하거나 하루 1~2회 주기적 호출로 최신화.
게임 서버는 이용자 토큰을 영속 저장 금지 클라이언트가 요청 시점마다 User Access Token을 함께 전달하고, 게임 서버는 그 토큰으로 검증 API를 호출.

게임 식별자 정리

스토브 인증·API에서 사용하는 게임 식별자 용어는 아래와 같아요.
식별자는 Game ID(문자열) 를 표준으로 사용해요.

용어 설명 비고
Game ID 게임을 식별하는 고유 문자열.
환경(Sandbox/Live)과 무관하게 동일하게 유지.
제재 API 등에서 공식 제공하는 표준 식별자.
Game No 게임을 구분하기 위해 부여된 숫자 코드. 현재 연동에서는 사용하지 않아요. 식별자는 Game ID를 사용해요.
Service ID Game No와 Game ID가 혼용되어 모호한 표현. 모호하여 사용하지 않아요.
  • 스토브 플랫폼 내부의 회원 식별 번호는 member_no(숫자형)예요.
  • 현재 연동 게임은 회원 식별자로 guid를 전달받아요.

인증 부가 기능

기본 인증 외에 스토브 인증 시스템이 제공하는 부가 기능이에요.

기능 제공 플랫폼 설명
이메일 인증 Mobile SDK 아이디 이메일로 인증코드/링크를 전송해 본인을 확인. SDK 2.8.0 이후 모바일 이메일 계정 인증 필수.
스토브 이메일 계정은 가입 메일, 3rd Party 계정은 '내 정보'에서 설정한 보조 이메일로 진행.
웹 인증 (GNB / 로그인 URL) Web 웹 사이트에서 스토브 로그인 활용.
GNB 방식(권장)은 반응형 GNB UI 모듈 제공, 로그인 URL 방식은 스토브 로그인 페이지로 직접 연결.
xxx.game.onstove.com 도메인에서 사용 가능.
회원 제재 상태 조회 Server 게임 서버가 스토브 API로 회원의 플랫폼 제재·게임 제재·글쓰기 제재 상태를 조회.
복수 제재가 존재해도 우선순위에 따라 단일 코드로 응답.

연동 가이드


플랫폼별 사전 준비

자사 게임의 출시 형태에 따라 필요한 플랫폼의 사전 준비만 진행하면 돼요.

플랫폼 필요 항목
Mobile ㆍ Mobile SDK 다운로드 및 프로젝트 적용
ㆍ App ID·Client ID 설정
ㆍ iOS·Android 각각 패키지/번들 ID 등록
PC ㆍ PC SDK(PCSDK3) 다운로드 및 프로젝트 적용
ㆍ App ID·Client ID 설정
ㆍ 스토브 PC 클라이언트(런처)를 통한 게임 실행 동선 확인
Server ㆍ API Access Token 발급 키 신청
ㆍ 게임ID를 퍼블리싱 기술 담당자에게 전달해 client_id·client_secret·service_id 발급
ㆍ 서비스 환경별(Live, Sandbox) 별도 발급
Web ㆍ 연동 웹 서비스 도메인이 xxx.game.onstove.com이어야 사용 가능
ㆍ 4차 도메인 연결은 담당 기술PM을 통해 적용
ㆍ 외부 인프라 사용 시 SSL 인증서 발급 필요
inflow_path 등 유입경로 코드도 담당 기술PM을 통해 발급

환경 분리 발급은 필수예요
키와 토큰은 반드시 환경(Live/Sandbox)별로 분리해서 발급받고 혼용하지 마세요.
환경을 섞어 사용하면 검증 API에서 40105(client_id/client_secret 불일치) 또는 41002(service_id 불일치) 오류가 발생해요.

전체 인증 흐름

플랫폼(Mobile/PC/Web)이 달라도 인증이 진행되는 순서는 동일해요. 모두 아래 5단계를 따르며, 각 단계를 구현하는 구체적인 방법만 플랫폼에 따라 달라요.

단계 작업 주체 설명
1 이용자 로그인 클라이언트 (SDK/Web) SDK/웹 모듈을 통해 스토브 로그인 수행. 성공 시 User Access Token 발급.
2 User Access Token 조회 클라이언트 사용 시점마다 SDK API로 최신 토큰을 조회. 캐싱 금지.
3 서버로 토큰 전달 클라이언트 → 게임 서버 API 호출이 필요한 시점에 User Access Token을 게임 서버로 함께 전달.
4 API Access Token 발급/갱신 게임 서버 ↔ 스토브 게임 서버가 client_id/client_secret로 API Access Token을 발급·갱신.
5 유효성 검증 및 분기 게임 서버 ↔ 스토브 스토브 검증 API로 User Access Token을 검증.
응답 code에 따라 정상 진입·재로그인 유도·접근 차단을 분기.

검증 API는 게임 서버에서만 호출해요
클라이언트에서 직접 호출하면 API Access Token이 노출돼 보안 문제가 생겨요.
검증은 게임 서버에서 수행하고, 클라이언트는 결과만 전달받아요.

환경 구분 안내

스토브는 개발 단계와 운영 단계를 분리하기 위해 Sandbox와 Live 두 환경을 제공해요.
키 발급·도메인·검증 API 모두 환경별로 별도 운영되므로 혼용하지 않도록 주의해요.

구분 용도 사용 시점
Sandbox 개발·테스트 환경 SDK 연동 검증, 시나리오별 응답 코드 확인, QA.
실제 이용자에게 노출되지 않음.
Live 상용 서비스 환경 실제 이용자 대상 서비스.
출시 후에도 신규 기능 검증은 Sandbox에서 먼저 진행 후 Live 반영.
  • 환경별로 client_id·client_secret·service_id를 별도 발급받아요.
  • 검증 API의 game_id와 보유한 API Access Token의 service_id가 다르면 41002 오류가 발생해요. 환경·게임별로 분리 관리하세요.

개발하기


모바일

사전 준비

  • Auth.login(Android) / [SGSAuth login](iOS) / Auth.Login(Unity·Unreal) 호출이 완료된 상태여야 해요. 미로그인 상태에서는 accessTokennull을 반환해요.
  • 토큰을 클라이언트에 캐싱하지 말고 사용 시점마다 SDK에서 재조회하세요. SDK는 만료시간의 80%에 도달하면 자동 갱신을 수행하므로, 매번 SDK에서 가져온 값이 항상 최신이에요.
  • 자동 갱신은 앱 프로세스가 실행 중일 때만 동작해요. 백그라운드에서 프로세스가 종료된 상태에서는 갱신이 멈추므로, 포그라운드 복귀 시점에는 호출 결과를 검증하고 만료된 경우 재로그인 흐름으로 유도하세요.
  • 게임 서버에 토큰을 넘겨야 하는 경우에도 서버 측에 저장하지 말고, 클라이언트 호출이 발생할 때마다 함께 전달하세요.

개발 흐름

  1. 게임 클라이언트가 Auth.accessToken?.token(Kotlin) / [[SGSAuth accessToken] token](iOS) 등 플랫폼별 API로 최신 AccessToken을 조회해요.
  2. 반환값이 null이면 미로그인 또는 로그아웃 상태이므로 로그인 흐름으로 유도해요.
  3. 게임 서버에 토큰을 전달해야 하면 호출 시점에 SDK에서 받은 토큰을 그대로 전달해요. 서버 측에는 저장하지 말고 매 요청마다 새로 전달받으세요.
  4. 게임 서버는 스토브 플랫폼의 Game User Access Token 유효성 검증 API로 토큰을 검증한 뒤 정상 진입·재로그인 유도·접근 차단 등을 분기해요. (검증 API는 게임 서버 가이드 참고)

자동 갱신 동작은 다음 시퀀스로 진행돼요:

트러블슈팅

AccessToken은 캐싱하지 마세요
SDK가 만료시간의 80% 시점에 자동으로 갱신하기 때문에, 매번 Auth.accessToken을 호출하는 방식이 항상 최신값을 보장해요. 클라이언트나 게임 서버에 저장해 둔 토큰을 재사용하면 만료/갱신 후 무효화된 토큰으로 인증 오류가 발생해요.

상황원인조치
accessTokennull 반환미로그인 또는 로그아웃 직후 상태호출 전에 Auth.accessToken != null을 확인하고, null이면 로그인 흐름으로 유도하세요.
API 호출 시 401 인증 실패 (만료된 토큰)자동 갱신이 동작하지 못한 채 토큰이 만료됨 (예: 장기 백그라운드 후 복귀)사용 시점마다 Auth.accessToken을 다시 조회해 최신 토큰을 확보하세요. 그래도 만료된 경우 재로그인을 유도하세요.
게임 서버에 저장한 토큰으로 호출 시 실패클라이언트의 재로그인·로그아웃·자동 갱신으로 토큰이 무효화됨게임 서버는 토큰을 영속 저장하지 말고, 클라이언트 요청과 함께 받은 최신 토큰을 사용해 스토브 검증 API를 호출하세요.
자동 갱신이 동작하지 않음앱 프로세스가 백그라운드에서 종료되어 SDK 콜백이 멈춤포그라운드 복귀(onResume / applicationDidBecomeActive) 시점에 토큰을 재조회하고, 만료 시 재로그인을 유도하세요.

샘플 코드

csharp
public void GetToken()
{
    string token = Auth.AccessToken.Token;
}

PC (PCSDK)

사전 준비

  • BaseSDK 초기화(Base_RestartAppIfNecessaryAsyncBase_InitializeEx)와 로그인 완료가 선행돼 있어야 해요. 초기화 전에 호출하면 BASE_NOT_INITIALIZED(16)가 반환돼요.
  • AccessToken 수신용 버퍼는 충분한 크기로 미리 할당해야 해요. 길이가 부족하면 INVALID_PARAM(5)이 반환될 수 있어요.
  • API Access Token 발급용 client_id / client_secret / service_id는 게임 서버가 보유해야 하며 클라이언트에 노출하지 않아요.
  • 토큰은 캐싱하지 말고 필요 시점마다 SDK로 재조회해요. 이용자의 재로그인·로그아웃·세션 변경으로 언제든 무효화될 수 있어요.

개발 흐름

  1. 게임 클라이언트는 Base_GetAccessToken(buffer, length)을 호출해 최신 User Access Token을 가져와요.
  2. 반환된 결과(Result)를 IsSuccessful()로 검증해요. (C/C++·C# 모두 result.IsSuccessful())
  3. 게임 서버에서 토큰을 사용해야 하면 클라이언트가 토큰을 게임 서버로 전달해요. 서버 측에 저장해 두지 않고 호출 시점에 다시 받아 전달해요.
  4. 게임 서버는 스토브 플랫폼의 Game User Access Token 유효성 검증 API를 호출해 토큰을 2차 검증해요. 이때 API Access Token이 Authorization 헤더에 필요해요.
  5. 검증 결과 응답 코드에 따라 정상 진입·재로그인 유도·접근 차단 등 후속 처리를 분기해요.

트러블슈팅

상황원인해결 방법
게임 시작 직후 Base_GetAccessToken을 호출했더니 BASE_NOT_INITIALIZED(16)가 반환돼요Base_RestartAppIfNecessaryAsync는 비동기라 콜백이 오기 전에는 초기화가 완료되지 않아요. 콜백의 restartAppIfNecessary == false 분기에서 Base_InitializeEx를 호출해야 초기화가 완료되며, 그 이전에 토큰을 가져오면 16번 오류가 발생해요.Base_RestartAppIfNecessaryAsync 콜백에서 restartAppIfNecessary == false를 확인한 뒤 Base_InitializeEx를 호출하고, 초기화 성공 이후부터 토큰 조회를 해야 해요. 보통 타이틀 화면 진입 전 초기화를 마치고, 로그인 단계 이후에 토큰을 조회하면 문제없어요.
이용자가 한참 플레이하다가 서버 호출 시 INVALID_ACCESS_TOKEN(19)가 반환돼요Base_GetAccessToken은 호출할 때마다 최신 토큰을 반환하므로 정상 환경에서는 19번 오류가 발생하지 않아요. 발생한다면 일시적 네트워크 장애나 비정상적인 SDK 상태가 원인이에요.19번이 반환되면 게임을 계속 진행하지 말고, "스토브 PC 클라이언트를 통해 다시 시작해 주세요" 안내 후 게임을 종료해야 해요. 토큰은 멤버 변수에 캐싱하지 말고 게임 서버 호출 직전마다 Base_GetAccessToken으로 가져오면 문제없어요.
토큰 문자열이 중간에 잘리거나 INVALID_PARAM(5)가 반환돼요토큰 길이는 가변이고 향후 확장될 수 있어 작은 버퍼(예: 256·1024바이트)로는 부족해요.4096 크기의 wchar_t 버퍼를 할당해 전달해야 해요. 받은 토큰은 길이로 가공하지 말고 게임 서버로 그대로 전송하면 문제없어요.
FAIL(1)가 반환돼요Base_GetAccessToken은 로컬 캐시 조회라 통신을 거치지 않으므로 정상 환경에서는 1번 오류가 발생하지 않아요. 발생한다면 SDK 내부 비정상 상태(메모리 손상, 토큰 액터 누락 등)가 원인이에요.19번과 동일하게 게임을 계속 진행하지 말고, "스토브 PC 클라이언트를 통해 다시 시작해 주세요" 안내 후 게임을 종료해야 해요.

User Access Token은 캐싱하면 안 돼요
발급 후 6시간만 유효하고 이용자의 재로그인·로그아웃으로 언제든 변경돼요. 서버 측 저장이나 클라이언트 캐시는 만료/변경 토큰으로 인한 인증 오류의 원인이 돼요. 반드시 사용 시점마다 Base_GetAccessToken으로 최신 값을 받아 사용해요.

API Access Token은 게임 서버에서만 관리해요
30일 유효한 서버 간 인증용 토큰이라 클라이언트로 노출하면 안 돼요. 게임 서버가 client_id/client_secret로 발급받고 expires_in 기준으로 갱신해요. 기존 토큰의 잔여 유효 기간이 30% 이상이면 동일 토큰이, 미만이면 신규 토큰이 발급돼요.

샘플 코드

cpp
// 게임 루프에서 Base_RunCallback() 호출이 등록돼 있다고 가정합니다.
constexpr uint32_t kTokenBufferSize = 4096;
wchar_t accessToken[kTokenBufferSize] = { 0 };

auto result = Stove::PCSDK::Base::Base_GetAccessToken(accessToken, kTokenBufferSize);
if (result.IsSuccessful())
{
    // accessToken 문자열을 게임 서버로 전송하여 유효성 검증을 수행하세요.
}
else
{
    // 실패 시 로직(재로그인 유도, 사용자 안내 등)을 구현해 주세요.
}

Server

사전 준비

  • 게임 서버가 client_id / client_secret / service_id를 보유하고 있어야 해요.
    발급 절차와 환경(Live/Sandbox) 분리는 위 2. 연동 가이드 → 토큰 발급 사전 준비를 참고하세요.
  • 클라이언트로부터 Game User Access Token을 요청 시점마다 전달받는 구조여야 해요. 게임 서버에 캐싱하지 않아요.

개발 흐름

  1. 클라이언트가 게임 서버에 Game User Access Token을 전달해요.
  2. 게임 서버는 보유 중인 API Access Token의 잔여 유효기간을 확인해요. (발급 시 받은 expires_in 기준)
  3. 토큰이 없거나 잔여 30% 미만이면 POST /auth/v5/server_token을 호출해 API Access Token을 발급·갱신해요.
    30% 이상 남아 있다면 동일한 토큰이 반환되므로, 응답의 access_token을 그대로 사용해도 돼요.
  4. POST /member/v3.0/{game_id}/token/verify를 호출해 클라이언트로부터 받은 Game User Access Token의 유효성을 검증해요.
    Authorization 헤더에는 Bearer {API Access Token}을 넣어요.
  5. 응답 code에 따라 정상 진입(code == 0), 재로그인 유도, 기기 등록 유도, 접근 차단 등으로 분기해요.
    응답 value.guid(GUID 기반 게임) 또는 value.member_no로 이용자를 식별해요.

트러블슈팅

응답 code 별 처리 방안이에요. 상세 응답 코드·메시지 스펙은 API & SDK 레퍼런스 메뉴를 참고하세요.

응답 code상황처리 방안
40000Game User Access Token이 잘못되었거나 만료, 요청 Body 오류클라이언트에 재로그인을 유도하고, 요청 Body가 올바른지 확인하세요.
40101API Access Token이 잘못됨 (Authorization 헤더 값 오류)API Access Token을 재발급한 뒤 재시도하세요.
40103API Access Token 만료POST /auth/v5/server_token을 호출해 갱신한 뒤 재시도하세요.
40105발급 API 호출 시 client_id / client_secret 불일치환경(Live/Sandbox)별 키를 혼용하고 있지 않은지 확인하세요.
41002검증 API path의 game_id와 보유한 API Access Token의 service_id가 다름환경·게임별로 API Access Token을 분리해 발급·관리하세요.
46217(Mobile 기기등록 게임 한정) 정회원인데 기기 미등록클라이언트의 기기 등록 동선으로 유도하세요.
PC SDK 환경에서 획득한 토큰으로 검증할 때는 발생하지 않아요.
50000Unknown error일시적 오류일 수 있으니 재시도 후, 지속되면 기술PM 담당자를 통해서 문의주세요.

API Access Token은 게임 서버 외부로 노출하면 안 돼요
클라이언트·외부 시스템·로그 등에 출력하지 않도록 주의하세요. 노출 시 즉시 재발급이 필요해요.

여러 서버 인스턴스의 토큰 수명을 분리하려면 instance_id를 사용하세요
instance_id를 지정하지 않으면 client_id 기준으로 모든 서버에 동일한 토큰이 내려가요.
인스턴스별 발급·갱신 주기를 분리하고 싶다면 발급 요청 시 instance_id를 함께 전달하세요.

샘플 코드

API Access Token 발급(POST /auth/v5/server_token)과 Game User Access Token 유효성 검증(POST /member/v3.0/{game_id}/token/verify) 호출 예제예요.

Base URL은 환경(Live/Sandbox)에 맞춰 교체해 주세요
운영 환경에서는 하드코딩 대신 환경 변수(예: STOVE_API_BASE_URL)나 프레임워크 설정 파일로 분리해 환경별로 주입하는 것을 권장해요.

java
// Java 25 LTS — java.net.http.HttpClient + Jackson(ObjectMapper)
import com.fasterxml.jackson.databind.JsonNode;
import com.fasterxml.jackson.databind.ObjectMapper;
import java.net.URI;
import java.net.http.HttpClient;
import java.net.http.HttpRequest;
import java.net.http.HttpResponse;
import java.time.Duration;
import java.util.Map;

ObjectMapper mapper = new ObjectMapper();
String baseUrl = "https://api.onstove.com";
String serviceId = "STOVE_GAME";
String callerId = serviceId + "_SERVER";

try (HttpClient client = HttpClient.newBuilder()
        .connectTimeout(Duration.ofSeconds(5))
        .build()) {

    // 1) API Access Token 발급
    String issueBody = mapper.writeValueAsString(Map.of(
            "client_id", "com.stove.stovegame.clientid",
            "client_secret", clientSecret,
            "service_id", serviceId,
            "instance_id", "server001"));

    HttpRequest issueReq = HttpRequest.newBuilder(URI.create(baseUrl + "/auth/v5/server_token"))
            .header("Content-Type", "application/json")
            .header("caller-id", callerId)
            .POST(HttpRequest.BodyPublishers.ofString(issueBody))
            .build();
    HttpResponse<String> issueRes = client.send(issueReq, HttpResponse.BodyHandlers.ofString());
    JsonNode issueData = mapper.readTree(issueRes.body());
    if (issueData.path("code").asInt() != 0) {
        // 트러블슈팅 표 참고 (40105 등)
        throw new IllegalStateException("Token issue failed: " + issueData.path("code"));
    }
    String apiAccessToken = issueData.path("response_data").path("access_token").asText();

    // 2) Game User Access Token 유효성 검증
    String verifyBody = mapper.writeValueAsString(Map.of(
            "access_token", gameUserAccessToken));

    HttpRequest verifyReq = HttpRequest.newBuilder(
            URI.create(baseUrl + "/member/v3.0/" + serviceId + "/token/verify"))
            .header("Content-Type", "application/json")
            .header("Authorization", "Bearer " + apiAccessToken)
            .header("caller-id", callerId)
            .POST(HttpRequest.BodyPublishers.ofString(verifyBody))
            .build();
    HttpResponse<String> verifyRes = client.send(verifyReq, HttpResponse.BodyHandlers.ofString());
    JsonNode verifyData = mapper.readTree(verifyRes.body());
    if (verifyData.path("code").asInt() == 0) {
        JsonNode value = verifyData.path("value");
        // value.path("guid").asLong() 또는 value.path("member_no").asLong() 로 사용자 식별
    } else {
        // 트러블슈팅 표 참고 (40000 / 40101 / 41002 / 46217 등)
    }
}

자주 묻는 질문



Q1. User Access Token을 서버에 저장해서 재사용해도 되나요?
A. User Access Token은 캐싱하거나 서버에 저장하여 재사용하면 안 돼요.
발급 후 6시간 동안만 유효하며, 이용자의 재로그인·새로고침·로그아웃 등의 행위로 언제든지 변경될 수 있어요.
만료 또는 변경된 토큰으로 인해 인증 오류(검증 실패)가 발생할 수 있으므로, 반드시 필요한 시점마다 실시간으로 SDK를 통해 조회하여 사용해야 해요.
Q2. API Access Token은 어떻게 갱신해야 하나요?
A. 게임 서버는 주기적으로 API Access Token 발급 API를 호출하여 서버 접근 토큰을 갱신하거나, expires_in을 저장해 만료 전에 발급 API를 최신화해야 해요.
발급 API 호출 시 기존 토큰의 유효 기간이 30% 이상 남은 경우 기존 토큰을 그대로 전달하고, 30% 미만이면 신규 토큰을 발급해요.
기존에 발급된 토큰은 유효 기간까지 계속 사용할 수 있어요.
Q3. 멀티 플랫폼(Mobile + PC + Web) 게임은 인증을 어떻게 구성하나요?
A. 각 플랫폼별로 클라이언트 인증(Mobile SDK / PC SDK / Web)을 따로 연동하고, 게임 서버에서 공통의 API Access Token 발급·검증 로직을 두면 돼요.
User Access Token은 플랫폼마다 발급 방식이 다르지만 검증 API(/member/v3.0/{game_id}/token/verify)는 동일하므로, 게임 서버는 어느 환경에서 들어온 토큰이든 같은 흐름으로 처리할 수 있어요.
스토브 회원 식별자(guid 또는 member_no)도 플랫폼과 무관하게 동일해 계정 연속성이 유지돼요.
Q4. 웹 인증 시 GNB 방식과 로그인 URL 방식 중 어떤 것을 선택해야 하나요?
A. GNB 방식을 권장해요.
Javascript 모듈을 통해 스토브 GNB UI와 기능으로 연동하므로, PC·태블릿·모바일 모든 플랫폼에서 반응형으로 구성할 수 있고 서비스별 커스텀도 용이해요.
GNB 연동 방식이 아닌 웹 서비스에서 스토브 로그인 페이지를 직접 연동해야 하는 경우에는 로그인 URL 방식을 사용하면 돼요.
Q5. 게임서버에서 제재 상태를 조회할 때 복수의 제재가 있으면 어떻게 처리하나요?
A. 복수 제재가 존재해도 우선순위에 따라 단일 코드로 응답해요.
플랫폼 제재가 하나라도 존재하면 최우선으로 플랫폼 제재 코드(403101~403103)를 반환해요.
플랫폼 제재가 없고 게임 제재가 있으면 403201, 글쓰기 제재만 있으면 403202를 반환해요. 클라이언트는 code 값을 기준으로 이용자 접근 차단 및 메시지를 처리하면 돼요.
Q6. 제재 API에서 game_id, game_no, service_id 중 어떤 식별자를 사용해야 하나요?
A. 신규 API 연동 및 가이드에서는 반드시 Game ID(문자열)를 사용해야 해요.
Game No(숫자 코드)는 레거시 시스템에서 쓰이던 값으로, 현재 연동에서는 사용하지 않아요.
"Service ID"라는 표현은 모호성을 유발하므로 가이드 및 코드 내에서 사용하지 않는 것을 권장해요.



직접 문의하고 싶으신가요? stove.developers@smilegate.com