[보안] 엑세스 토큰 서명키(access token signing key)란 무엇인가?

웹 서비스·앱·API 인증에서 가장 중요한 요소 중 하나가 바로 엑세스 토큰(access token)이다. 최근 여러 보안 이슈에서 “엑세스 토큰 서명키가 노출되었다”는 말이 나오는 경우가 있는데, 서명키는 일반 사용자뿐 아니라 개발자에게도 쉽게 눈에 띄지 않는 매우 민감한 비밀 키이다. 한 번 노출되면 인증 체계 전체가 흔들릴 수 있는 수준의 심각한 문제로 이어질 수 있다.

---

1. 엑세스 토큰(access token)은 무엇인가?

엑세스 토큰은 사용자가 로그인한 뒤, 서버가 그 사용자를 인증하기 위해 발급하는 디지털 신분증이다.

일반적인 흐름은 다음과 같다.

• 사용자가 아이디/비밀번호, 소셜 로그인 등으로 인증
• 서버가 인증에 성공하면 엑세스 토큰 발급
• 앱/웹은 이후 모든 API 요청에 토큰을 포함해 전송
• 서버는 토큰을 검증하고, 유효하면 개인정보·주문·결제 등 민감 정보에 대한 접근을 허용

따라서 엑세스 토큰은 다음과 같은 API 접근에 사용된다.

• 주문·결제 내역 조회
• 사용자 프로필 조회
• 배송지 주소·전화번호 조회
• 장바구니·위시리스트 등 계정 기반 기능 호출

정리하면, 엑세스 토큰 = 인증된 사용자임을 증명하는 가장 중요한 키이다.

---

2. JWT(Json Web Token) 구조 간단히 이해하기

많은 서비스가 엑세스 토큰을 JWT(Json Web Token) 형식으로 발급한다. JWT는 크게 세 부분으로 나뉜다.

HEADER.PAYLOAD.SIGNATURE

각 부분은 다음과 같은 역할을 한다.

• Header - 어떤 알고리즘으로 서명했는지 등의 메타정보 - 예: {"alg": "HS256", "typ": "JWT"}
• Payload - 실제 담고 싶은 데이터(클레임, claims) - 예: user_id, email, role, exp(만료 시간) 등
• Signature - 위 Header + Payload가 변조되지 않았음을 증명하는 서명 값

JWT 구조 그림

┌───────────────┐   ┌──────────────────────┐   ┌──────────────────────────────┐
│    Header     │ . │            Payload        │ . │                     Signature           │
└───────────────┘   └──────────────────────┘   └──────────────────────────────┘

예)
Header  : {"alg": "HS256", "typ": "JWT"}
Payload : {"user_id": 123, "role": "USER", "exp": 1735660000}
Signature : HMAC-SHA256(Header + Payload, 서명키)

클라이언트(브라우저·앱)는 토큰 전체를 서버로 보내고, 서버는 Signature를 검증하여 이 토큰이 서버가 발급한 것인지, 중간에 변조되지 않았는지 확인한다.

---

3. 엑세스 토큰 “서명키(Signing Key)”란 무엇인가?

서명키(Signing Key)는 위에서 본 JWT의 Signature를 만들기 위해 사용하는 비밀 키이다. 서버는 이 서명키를 이용해 Header·Payload를 입력으로 받아 서명값을 만들고, 나중에 토큰이 다시 들어왔을 때 같은 키로 검증한다.

서명키가 하는 일은 다음과 같다.

• 이 토큰이 정상적으로 서버에서 발급된 것인지 확인
• 중간에 누가 Payload를 수정하거나 위조하지 않았는지 검증

따라서 서명키는 절대 외부에 노출되면 안 되는 최상위 비밀 값이다. 쉽게 말해, “서버가 토큰에 도장을 찍는 데 사용하는 도장 자체”에 해당한다.

---

4. HS256 vs RS256: 서명 방식에 따른 차이

JWT Header의 alg 필드에는 대표적으로 HS256 또는 RS256 등의 알고리즘이 들어간다. 두 방식은 서명키의 구조와 관리 방식이 다르다.

4-1. HS256 (대칭키 방식)

• 대칭키(Symmetric Key) 방식이다.
• 서명에 사용하는 키와 검증에 사용하는 키가 같다.
• 즉, 하나의 비밀키를 가지고 sign과 verify를 모두 수행한다.

서버: secretKey 로 JWT 서명 생성
서버: secretKey 로 JWT 서명 검증

장점:

• 구현이 간단하다.
• 성능이 상대적으로 빠르다.

단점:

• 하나의 비밀키가 노출되면 누구나 토큰을 만들고 검증할 수 있는 상태가 된다.
• 여러 서비스가 같은 키를 공유하면, 한 군데만 뚫려도 전체가 위험해진다.

4-2. RS256 (비대칭키 방식)

• 비대칭키(공개키/개인키, Public/Private Key) 방식이다.
• 개인키(Private Key)로 서명하고, 공개키(Public Key)로 검증한다.

서버: Private Key 로 JWT 서명 생성
클라이언트/다른 서버: Public Key 로 JWT 서명 검증

장점:

• 서명에 사용되는 개인키는 서버 내부에만 보관하고, 검증용 공개키는 외부 서비스에 공유해도 된다.
• 공개키가 유출되어도 서명 생성은 불가능하다.
• 여러 마이크로서비스·외부 파트너가 토큰을 검증해야 할 때 구조가 유리하다.

단점:

• HS256보다 계산 비용이 크고 구현이 조금 더 복잡하다.

4-3. 정리: HS256 vs RS256

구분	HS256	RS256
키 구조	하나의 비밀키(대칭키)	개인키 + 공개키(비대칭키)
서명 / 검증	같은 키로 서명·검증	개인키로 서명, 공개키로 검증
유출 위험	키 하나만 노출돼도 위조·검증 모두 가능	공개키 유출은 크게 문제 아님, 개인키 유출만 치명적
사용 예	단일 서비스 내부, 간단한 시스템	대규모 서비스, 외부 파트너 연동, 마이크로서비스 구조

실무에서는 내부 서비스만 쓰는 작은 시스템은 HS256, 여러 서비스와 외부 파트너가 섞여 있는 큰 시스템에서는 RS256 또는 다른 비대칭 알고리즘을 많이 사용한다.

---

5. 서명키가 노출되면 왜 위험한가?

서명키는 엑세스 토큰의 신뢰성을 보장하는 마지막 보루이다. 이 키가 노출되면 다음과 같은 일이 발생할 수 있다.

① 공격자가 가짜 토큰을 만들 수 있다

서명키를 가진 공격자는 임의로 user_id, role, exp를 바꾸고, 해당 내용에 서명을 붙여 서버가 신뢰하는 토큰처럼 보이게 만들 수 있다.

예)
- 관리자 권한 role을 가진 토큰 위조
- 만료 시간이 매우 길게 설정된 토큰 발급
- 특정 사용자 계정으로 위장한 토큰 생성

② 로그인 없이 개인정보 API 접근 가능

위조한 토큰을 이용해:

• 개인정보 조회 API
• 주문 내역, 주소, 연락처 조회 API
• 계정 설정 변경 API

등에 접근할 수 있게 된다. 이 단계에서는 서버가 정상 사용자와 공격자를 구분할 수 없게 된다.

③ 여러 서비스가 같은 서명키를 공유하면 피해가 확산된다

대규모 서비스에서는 여러 마이크로서비스가 같은 서명키를 공유하는 경우가 많다. 이때 한 곳에서 키가 유출되면 전체 서비스가 한 번에 뚫리는 결과로 이어진다.

④ 인증·권한 시스템 자체가 붕괴되는 수준의 사고

서명키 노출은 단순한 코드 버그나 화면 오류가 아니라, 인증·권한 시스템 전체가 더 이상 신뢰할 수 없게 되는 상황이다. 그래서 클라우드 사업자들도 서명키를 반드시 KMS(Key Management Service)나 전용 비밀 관리자(Vault)에 보관하도록 권장한다.

---

6. 서명키가 노출되었을 때의 대응

서명키 노출이 의심되거나 확인되면 다음과 같은 조치가 필요하다.

1. 기존 서명키 즉시 폐기 더 이상 해당 키로 서명·검증을 하지 않도록 설정을 변경한다.
2. 새로운 서명키 생성 및 배포 모든 관련 서비스의 설정을 업데이트한다.
3. 기존 토큰 전부 강제 만료 이미 발급된 토큰은 더 이상 신뢰할 수 없기 때문에 재로그인을 요구한다.
4. 로그 분석 및 이상 접근 조사 누가, 언제, 어떤 API를, 어떤 IP에서 호출했는지 추적한다.
5. 필요 시 사용자 통지 및 관계 기관 신고 개인정보 접근 가능성이 있었다면 관련 법령에 따른 조치가 필요하다.

---

7. 정리

• 엑세스 토큰은 로그인한 사용자를 식별하는 디지털 신분증이다.
• JWT는 Header·Payload·Signature로 구성되며, Signature는 서명키로 생성한다.
• 서명키는 토큰이 위조되지 않았음을 검증하는 최상위 비밀키이다.
• HS256은 대칭키 방식, RS256은 비대칭키 방식으로 서명·검증을 수행한다.
• 서명키가 노출되면 공격자가 임의의 토큰을 만들어 사용자를 위장할 수 있다.
• 이는 개인정보 조회·계정 탈취·권한 상승 등으로 이어질 수 있는 중대 보안 사고이다.
• 노출 시에는 즉시 키 폐기, 토큰 만료, 로그 조사 등 강력한 대응이 필요하다.

결국 엑세스 토큰 서명키는 인증 시스템의 심장부에 해당하는 값이며, 이 값을 안전하게 관리하지 못하면 서비스 전체의 보안 신뢰도가 무너질 수 있다.