SSH와 JWT 인증에 대하여

SSH 키 기반 인증과 JWT(JSON Web Token) 인증 방식을 비교하며, 두 기술이 어떻게 사용자 인증이라는 동일한 목표를 달성하는지, 그리고 그 근본적인 원리가 무엇인지 탐구해보았습니다.

학습 주제

• 오늘 공부한 주제: SSH 키 기반 인증과 JWT 인증 방식 비교 및 원리 이해
• 대화 제목: ssh와 jwt 비교
• 학습 날짜: 2026년 2월 9일

핵심 학습 내용

SSH 키 인증 vs JWT 인증

SSH와 JWT의 인증 메커니즘을 대응시켜 이해할 수 있었습니다.

1. 최초 신원 증명 단계:

• SSH: 클라이언트가 private key로 nonce를 서명하여 서버에 보내고, 서버는 public key로 검증합니다. 클라이언트가 자신을 증명하는 구조입니다.
• JWT: 클라이언트가 id/password를 전송하면, 서버가 이를 검증하고 user info를 private key/secret으로 서명하여 JWT를 발급합니다. 서버가 '이 사용자는 인증됨'이라고 보증하는 구조입니다.

핵심: SSH는 클라이언트가 자신을 증명하는 '신뢰 증명'이라면, JWT는 서버가 클라이언트의 신원을 보증하는 '신뢰 증명서 발급'에 가깝습니다.

2. 인증 결과물:

• SSH: 인증 결과는 서버 메모리에 유지되는 '세션'입니다 (stateful).
• JWT: 인증 결과는 클라이언트가 소지하는 '토큰'입니다 (stateless).

3. 이후 요청 인증:

• SSH: 패킷마다 이미 열린 세션 ID로 인증됩니다.
• JWT: HTTP 요청마다 Authorization 헤더에 담긴 JWT의 서명을 서버가 검증합니다.

4. 신뢰의 근원:

• SSH: 서버가 믿는 것은 클라이언트의 public key입니다.
• JWT: 서버가 믿는 것은 자신의 secret/private key입니다.

5. 만료/종료:

• SSH: 연결이 끊기거나 idle timeout 시 세션이 종료됩니다.
• JWT: 토큰 자체에 명시된 exp claim에 따라 만료되며, refresh token 메커니즘을 통해 갱신될 수 있습니다.

JWT의 본질: '서버가 서버에게 하는 서명'

가장 큰 의문점 중 하나는 "서버가 서명하고, 또 서버가 검증하는 것이 맞는가?"였습니다. 이에 대한 답은 JWT 서명의 목적이 SSH와 다르다는 점에서 나왔습니다.

• SSH 서명 목적: 타인이 나를 믿게 하기 위함 (상대방에게 증명)
• JWT 서명 목적: 자신이 만든 토큰이 중간에 변조되지 않았는지 확인하기 위함 (위조 방지용 무결성 체크)

결론적으로, JWT의 서명은 **'서버가 자기 자신에게 하는 서명'**이며, 이는 암호학적으로는 MAC(Message Authentication Code) 구조와 동일합니다. 즉, JWT는 '인증 프로토콜'이라기보다는 **'서버가 발급한 상태 스냅샷에 대한 위조 방지 봉인 씰'**에 가깝습니다.

JWT의 실제 작동 방식

• 발행 시 입력: 인증 결과 데이터(payload)와 서버의 비밀키(HMAC의 경우) 또는 개인키(RSA/ECDSA의 경우)가 입력됩니다.
• 클라이언트 역할: 클라이언트는 받은 JWT를 HTTP 헤더에 담아 서버로 전송합니다.
• 토큰 손상/탈취/만료:
  • 변조: 서명 검증 실패로 즉시 차단됩니다.
  • 탈취: SSH private key 유출급의 심각한 보안 사고이며, HTTPS 및 짧은 access token, refresh token 활용으로 방지합니다.
  • 만료: exp claim 확인 후, refresh token으로 재발급 요청합니다.
• 다중 서버 환경: 모든 서버가 동일한 secret/public key를 공유하면, 어떤 서버든 동일한 토큰을 검증할 수 있습니다. 이는 세션 방식과 달리 서버 메모리 공유나 sticky session이 필요 없게 만들어 확장성을 높여줍니다.

이해한 내용

저는 다음과 같은 점들을 새롭게 이해하게 되었습니다.

• SSH와 JWT의 근본적인 작동 원리 차이: SSH는 클라이언트의 신원 증명을, JWT는 서버가 발급한 정보의 무결성을 보장하는 데 초점을 맞춥니다.
• JWT의 stateless 특성: 서버가 사용자 정보를 직접 기억할 필요 없이, 클라이언트가 소지한 토큰의 서명만 검증하면 되므로 확장성이 뛰어납니다.
• JWT의 보안 취약점과 보완책: 토큰 탈취 및 만료에 대한 위험성을 인지하고, HTTPS, 짧은 access token, refresh token, 그리고 RSA 서명과 같은 실무적인 보완책의 중요성을 알게 되었습니다.
• "서버가 서명하고 서버가 검증"의 의미: 이는 '상대방에게 증명'이 아닌 '자신이 만든 데이터의 무결성을 확인'하는 메커니즘임을 명확히 이해했습니다.
• JWT의 'User 객체 스냅샷'으로서의 역할: JWT는 단순한 인증 토큰을 넘어, 서버가 요청을 처리하는 데 필요한 사용자 정보(User Context)를 안전하게 전달하는 수단이라는 것을 깨달았습니다.

실전 적용

이 지식을 바탕으로 다음과 같은 실전 적용을 계획하고 있습니다.

• 개인 프로젝트에 JWT 적용: 현재 진행 중인 개인 프로젝트의 인증 부분을 JWT 기반으로 개선할 예정입니다. 특히, access token과 refresh token을 분리하고, HTTPS를 적용하여 보안성을 강화할 것입니다.
• 보안 관련 심화 학습: JWT의 약점을 보완하기 위한 다양한 전략(키 롤테이션, RBAC 모델 등)에 대해 더 깊이 공부할 계획입니다.

추가 학습 계획

• OAuth 2.0 및 OpenID Connect: JWT와 함께 많이 사용되는 인증/인가 프로토콜인 OAuth 2.0과 OpenID Connect에 대해 학습하여, 다양한 외부 서비스 연동 시의 인증 방식을 이해하고 싶습니다.
• API Gateway에서의 JWT 검증: MSA(Microservices Architecture) 환경에서 API Gateway가 JWT 검증을 어떻게 처리하는지에 대한 내용을 찾아보고 싶습니다.
• JWT 라이브러리별 특징 비교: Java Spring Security, Python FastAPI 등 다양한 프레임워크에서 제공하는 JWT 라이브러리의 특징과 장단점을 비교 분석하는 학습을 진행할 예정입니다.