ID Token, Access Token, Refresh Token에 관하여(OAuth2.0와 OIDC)

OAuth 2.0과 OIDC(OpenID Connect) 환경에서 ID Token, Access Token, Refresh Token이 어떻게 발급되고 사용되는지, 그리고 토큰 갱신(Rotation)과 서버 간의 역할 분담까지 전체 흐름에 대해 간략히 정리해보겠습니다.

모던 웹/모바일 애플리케이션 개발에서 인증과 인가는 필수 요소입니다. 특히 OAuth 2.0과 OIDC를 도입할 때 가장 헷갈리는 부분이 “토큰들이 정확히 언제, 어디서 발급되고 어떻게 쓰이는가”입니다. 인증 서버(Auth Server)와 리소스 서버(API Server)가 분리된 구조를 바탕으로, 클라이언트와 서버 간의 상호작용 전체 흐름을 시퀀스 다이어그램과 함께 살펴보겠습니다.

1. 최초 로그인 및 토큰 발급 (1 ~ 2단계)
   • 주체: Client ↔ Auth Server
   • 설명: 사용자가 아이디와 비밀번호를 입력해 로그인을 요청하면, 인증 서버는 검증 후 세 가지 토큰을 발급합니다.
   • ID Token (OIDC): 사용자의 신원 정보(이름, 이메일 등)가 담긴 JWT로, 클라이언트 화면에 프로필을 띄우는 데 사용됩니다.
   • Access Token (OAuth 2.0): API 서버에 데이터를 요청할 때 사용하는 임시 출입증입니다.
   • Refresh Token (OAuth 2.0): Access Token이 만료되었을 때 새로 발급받기 위한 마스터 열쇠입니다.
   • 특징
     

     구분	ID Token (OIDC)	Access Token (OAuth 2.0)	Refresh Token (OAuth 2.0)
     주요 목적	사용자 신원 인증 (Identity)	API 리소스 접근 권한 (Authorization)	Access Token 갱신 (Token Rotation)
     설계 방식	항상 JWT (Stateless)	주로 JWT (간혹 Opaque)	JWT 또는 Opaque 선택 가능
     수명 주기	짧음 (수 분 ~ 수 시간)	매우 짧음 (수 분 ~ 1시간)	긺 (수 주 ~ 수 개월)
     주요 저장소	SessionStorage / 메모리	메모리(JS 변수)	HttpOnly 쿠키
     서버 검증 방식	인증 서버의 공개키로 서명 검증	인증 서버 공개키 검증 또는 Introspection	DB/Redis 조회 또는 서명 검증

2. 토큰의 안전한 저장 전략 (Storage)
   • 탈취 위험을 최소화하기 위해 토큰의 성격에 따라 저장소를 다르게 가져가는 것이 보안 표준입니다.
     • ID Token (OIDC): SessionStorage 또는 메모리 (브라우저 종료 시 소멸)
     • Access Token (OAuth 2.0): 메모리(JS 변수, 상태 관리소) – 수명이 짧고 XSS 공격에 대비하기 위해 영구 저장소(LocalStorage)를 피합니다.
     • Refresh Token (OAuth 2.0): HttpOnly 쿠키 – 자바스크립트로 접근이 원천 차단되므로 악성 스크립트(XSS)로부터 안전합니다.(Set-Cookie: refreshToken=<Refresh Token>; HttpOnly; Secure)
3. 일반적인 API 호출 (3 ~ 4단계)
   • 주체: Client ↔ API Server
   • 설명: 클라이언트는 API 서버로 요청을 보낼 때 메모리에 보관 중인 Access Token을 HTTP 헤더(Authorization: Bearer <토큰>)에 담아 전송합니다. API Server는 토큰의 유효성을 검증하고 데이터를 응답합니다.
4. 토큰 만료와 무소음 갱신 (Silent Refresh & RTR) (5 ~ 8단계)
   • 주체: Client $\leftrightarrow$ API Server & Auth Server
   • 설명: 시간이 지나 Access Token이 만료되면 API 서버는 401 Unauthorized를 응답합니다.
   • 클라이언트는 이 에러를 감지한 뒤, 브라우저가 자동 동봉한 HttpOnly 쿠키(Refresh Token)를 실어 인증 서버로 재발급을 요청합니다(7단계)
   • 이 과정에서 최신 보안 기법인 RTR (Refresh Token Rotation)이 적용되어, 새로운 Access Token뿐만 아니라 새로운 Refresh Token도 함께 발급되며 기존 토큰은 폐기됩니다.
5. 요청 재시도 (9 ~ 10단계)
   • 주체: Client ↔ API Server
   • 설명: 새로 발급받은 Access Token을 메모리에 갱신한 뒤, 실패했던 원래의 API 요청을 자연스럽게 재시도하여 정상적인 데이터를 받아옵니다. 사용자는 로그인 화면으로 튕기는 불편함 없이 매끄러운 경험을 누릴 수 있습니다.

OAuth 2.0은 권한(인가)을 위임받는 프로토콜이고, OIDC는 그 위에 사용자 식별(인증) 레이어를 얹은 확장판입니다. 두 기술을 조합할 때는 각 토큰의 역할을 명확히 이해하고, Access Token은 헤더에, Refresh Token은 HttpOnly 쿠키에 나누어 담는 아키텍처를 구성하는 것이 안전한 웹/앱 서비스를 만드는 지름길입니다.