인증 토큰이란 무엇인가?
이 상황을 상상해 보십시오. 오전 9시, 뉴욕에서 기업 애플리케이션에 로그인합니다. 30분 후, 누군가가 도쿄에서 귀하의 계정에 접근합니다. 비밀번호는 한 번도 변경되지 않았습니다. 다중 인증(MFA) 토큰은 책상 위에 그대로 있습니다. 하지만 공격자는 탈취한 인증 토큰을 사용해 정문으로 들어오듯 시스템에 침입했습니다.
인증 토큰은 엔터프라이즈 시스템 전반에서 사용자의 신원을 검증하는 디지털 배지입니다. 이는 암호학적 자격 증명이므로 요청과 함께 비밀번호가 전송되지 않습니다. NIST Special Publication 800-63B-4에 따르면, 이러한 토큰은 현대 사이버보안 아키텍처에서 디지털 신원 보장의 기반을 형성합니다.
위 시나리오는 가상이 아닙니다. 2023년, 한 위협 행위자는 Okta's customer support system에 업로드된 지원 파일에서 세션 토큰을 추출한 뒤 이를 사용해 5개 고객의 활성 세션을 탈취했습니다. 비밀번호는 크랙되지 않았습니다. MFA 프롬프트에 응답한 일도 없었습니다. 유효한 토큰이 제시되었고, 시스템은 설계된 대로 정확히 동작했습니다.
토큰이 어떻게 작동하는지, 어디에서 실패하는지, 그리고 이를 어떻게 보호할 것인지를 이해하는 것은 공격자에게 열쇠를 넘겨주는 인프라와 버텨내는 인증 인프라를 가르는 기준입니다. 이 페이지에서는 이 세 가지를 모두 설명합니다.
인증 토큰이 보안 표적이 되는 이유
토큰은 신원 보안과 액세스 제어 아키텍처의 교차점에 위치합니다. 어떤 시스템에 인증할 때 실제 자격 증명을 모든 요청마다 들고 다니지는 않습니다. 대신 "이 사용자는 이미 자신의 신원을 증명했다"는 내용을 담은 토큰을 받습니다.
토큰을 탈취하면 공격자는 인증 자체를 완전히 우회합니다. 토큰을 위조하면 합법적인 사용자를 사칭합니다. 토큰 검증 방식이 조작되면 승인된 계정을 보유하지 않고도 권한을 상승시킵니다.
이 문제를 잘못 처리했을 때의 비용은 잘 문서화되어 있습니다. IBM's 2026 Cost of a Data Breach Report에 따르면 전 세계 평균 침해 비용은 사상 최고치인 499만 달러입니다. Verizon's 2026 Data Breach Investigations Report (DBIR)는 보고서 19년 역사상 처음으로 취약점 악용이 탈취된 자격 증명을 제치고 가장 큰 침해 진입 지점이 되었다고 밝혔습니다. 자격 증명은 올해까지 그 자리를 차지하고 있었으며, 탈취된 토큰은 이미 정문을 통과한 자격 증명입니다.
이러한 위험을 이해하려면 보안 팀은 먼저 조직이 배포하는 다양한 토큰 유형과 각 유형이 어떻게 고유한 보안 고려사항을 제시하는지 인식해야 합니다.
인증 토큰의 유형
조직은 보안 요구사항과 사용 사례에 따라 서로 다른 토큰 유형을 배포합니다.
- JSON Web Tokens (JWTs): 헤더-페이로드-서명 구조에 인코딩된 클레임을 담는 자체 포함형 토큰입니다. JWT는 서버가 데이터베이스 조회 없이 토큰을 검증하는 상태 비저장 검증을 가능하게 하므로, 분산 마이크로서비스 아키텍처에 적합합니다.
- OAuth 2.0 Tokens: OAuth 프레임워크는 함께 작동하는 두 가지 토큰 유형을 사용합니다. 액세스 토큰은 API 호출을 위한 수명이 짧은 자격 증명을 제공하고, 리프레시 토큰은 재인증 없이 새로운 액세스 토큰을 발급받습니다. 이러한 분리는 토큰 탈취로 인한 피해를 제한합니다.
- SAML (Security Assertion Markup Language) Assertions: 엔터프라이즈 싱글 사인온을 위해 신원 제공자와 서비스 제공자 간에 교환되는 XML 기반 토큰입니다. SAML은 레거시 엔터프라이즈 환경과 B2B 페더레이션 시나리오에서 여전히 지배적입니다.
- Session Tokens: 브라우저를 서버 측 세션 상태에 연결하는 서버 생성 식별자입니다. 상태 비저장 JWT와 달리 세션 토큰은 서버 저장소가 필요하지만 즉각적인 폐기 기능을 제공합니다.
- FIDO2/Hardware Tokens: WebAuthn API를 통해 공개 키 암호화를 사용하는 물리적 인증자입니다. 이러한 토큰은 암호학적 출처 바인딩을 통해 피싱 저항성을 제공하여 자격 증명이 합법적인 사이트에서만 작동하도록 보장합니다.
각 토큰 유형은 서로 다른 목적을 수행하지만, 보안 태세를 결정하는 공통 아키텍처 요소를 공유합니다. 강화는 바로 그 구성 요소에서 시작됩니다.
인증 토큰의 핵심 구성 요소
인증 토큰에는 보안 태세와 기능적 역량을 결정하는 특정 요소가 포함됩니다.
- 토큰 구조: JWT는 세 부분으로 구성됩니다. 헤더(RS256 또는 ES256과 같은 서명 알고리즘 지정), 페이로드(클레임 포함), 서명(암호학적 무결성 보장)입니다. SAML 어설션은 OASIS SAML V2.0 사양에 따른 XML 형식의 문장을 사용합니다.
- 토큰 메타데이터: 토큰은 페이로드 내에 메타데이터를 담습니다. 만료 타임스탬프(exp claim)는 유효 기간을 정의하고, 발급 시각 클레임(iat)은 토큰의 생성 시점을 나타내며, JWT ID (jti)는 폐기 추적을 위한 고유 식별자를 제공하고, 대상 제한(aud claim)은 서비스 간 토큰 재사용을 방지합니다.
- 세션 엔트로피: 웹 애플리케이션 세션 토큰에는 최소 엔트로피가 필요하며, 이는 암호학적으로 안전한 의사난수 생성기(CSPRNG)를 통해 생성되어야 합니다.
- 하드웨어 토큰 암호화: FIDO2 토큰은 WebAuthn 브라우저 API와 Client to Authenticator Protocol (CTAP)을 결합합니다. 개인 키는 보안 요소를 절대 벗어나지 않으며, 암호학적 출처 바인딩은 자격 증명이 합법적인 웹사이트에서만 작동하도록 보장합니다.
이러한 구성 요소는 워크플로로 결합되며, 토큰 보안의 성패는 바로 그 워크플로에서 갈립니다. 아래 섹션에서는 토큰이 다중 인증과 어떻게 상호작용하는지를 포함해 각 흐름을 추적합니다.
인증 토큰의 작동 방식
인증 토큰은 유형과 배포 맥락에 따라 서로 다른 워크플로를 따릅니다.
- JWT 인증 흐름: 사용자는 인증 서버에 자격 증명을 제출합니다. 서버는 자격 증명을 검증하고, 만료, 대상, 발급자 클레임이 포함된 JWT를 생성해 암호학적으로 서명한 뒤 클라이언트에 반환합니다. 이후 요청에서는 Authorization 헤더에 JWT를 포함합니다. 리소스 서버는 액세스를 허용하기 전에 서명을 검증하고 클레임을 확인합니다.
- OAuth 2.0 권한 부여 코드 흐름: 사용자는 보호된 리소스에 대한 액세스를 요청합니다. 인증과 동의가 완료되면 서버는 권한 부여 코드를 발급하고, 애플리케이션은 이를 액세스 토큰과 리프레시 토큰으로 교환합니다. 사용자는 API 호출에 수명이 짧은 액세스 토큰을 사용하고, 필요할 때 리프레시 토큰을 새 액세스 토큰으로 교환합니다.
- SAML 웹 브라우저 SSO: 사용자가 서비스 제공자 애플리케이션에 접근하려고 하면 신원 제공자로 리디렉션됩니다. 인증이 완료되면 IdP는 서명된 SAML 어설션을 생성해 서비스 제공자에게 게시하고, 이를 통해 인증된 세션이 설정되며 여러 애플리케이션 전반에서 싱글 사인온이 가능해집니다.
- 토큰 리프레시 및 로테이션: 수명이 짧은 액세스 토큰은 자주 만료되므로 리프레시 메커니즘이 필요합니다. 토큰 로테이션은 사용할 때마다 새로운 리프레시 토큰을 생성해 재생 공격을 방지합니다. 누군가 리프레시 토큰을 재사용하면 시스템은 잠재적 침해를 탐지하고 전체 토큰 패밀리를 폐기할 수 있습니다.
- 하드웨어 토큰 인증: 사용자는 디바이스의 보안 요소에서 키 쌍을 생성하여 FIDO2 인증자를 등록합니다. 인증 중 서비스는 인증자가 개인 키로 서명할 암호학적 챌린지를 전송합니다. 서비스는 등록된 공개 키를 사용해 서명을 검증합니다.
올바르게 구현되면 이러한 워크플로는 그 복잡성을 정당화합니다. 그 효과는 다음과 같습니다.
인증 토큰 사용 사례
인증 토큰은 엔터프라이즈 환경 전반의 특정 보안 및 운영 요구사항을 해결합니다.
- 엔터프라이즈 싱글 사인온: SAML 어설션을 사용하면 직원은 한 번 인증한 뒤 반복 로그인 없이 수십 개의 애플리케이션에 접근할 수 있습니다. Okta, Azure AD, Ping Federation과 같은 신원 제공자는 서비스 제공자가 신뢰하는 토큰을 발급하여 비밀번호 피로를 줄이고 액세스 거버넌스를 중앙화합니다.
- API 및 마이크로서비스 보안: OAuth 2.0 액세스 토큰은 분산 아키텍처에서 서비스 간 통신을 보호합니다. 각 microservice는 수신 토큰을 독립적으로 검증하여 공유 세션 저장소 없이 상태 비저장 확장성을 가능하게 합니다.
- 서드파티 권한 부여: OAuth 2.0은 사용자가 비밀번호를 공유하지 않고도 애플리케이션이 자신의 데이터에 접근하도록 승인하는 "Login with Google" 시나리오를 지원합니다. 권한 부여 서버는 애플리케이션이 접근할 수 있는 범위를 제한하는 스코프 기반 토큰을 발급합니다.
- 모바일 애플리케이션 세션: JWT는 모바일 앱에 지속적인 인증을 제공합니다. iOS Keychain 또는 Android KeyStore에 저장된 토큰은 앱 재시작 후에도 유지되어, 플랫폼별 보안 저장소를 통한 보안을 유지하면서도 매끄러운 사용자 경험을 제공합니다.
- 머신 간 인증: 자동화 시스템과 IoT 디바이스는 클라이언트 자격 증명 그랜트를 사용해 API 액세스용 토큰을 획득합니다. 이러한 토큰은 사람의 개입 없이 예약 작업, 모니터링 시스템, 디바이스 통신을 인증합니다.
패턴은 이들 모두에서 동일합니다. 토큰은 반복적인 자격 증명 전송을 수신 시스템이 자체적으로 검증할 수 있는 클레임으로 대체합니다.
인증 토큰의 주요 이점
토큰 기반 인증은 네 가지 측면에서 기존 세션 관리보다 우수합니다.
- 상태 비저장 확장성: 토큰 기반 시스템은 서버 측 세션 저장 요구사항을 제거하여, 개별 서비스가 공유 상태 없이 자격 증명을 독립적으로 검증하는 마이크로서비스 아키텍처를 가능하게 합니다.
- 도메인 간 싱글 사인온: SAML 2.0 어설션과 OpenID Connect는 싱글 사인온을 가능하게 합니다. 사용자는 한 번 인증한 뒤 반복 로그인 없이 여러 애플리케이션에 접근할 수 있어 인증 거버넌스를 중앙화할 수 있습니다.
- API 보안 및 Zero Trust: OAuth 2.0 클라이언트 자격 증명과 서명된 JWT를 사용하는 서비스 간 인증은 악성 서비스가 신뢰된 서비스를 사칭하는 것을 방지하며, 이는 제로 트러스트 아키텍처에 필수적입니다.
- 공격 표면 감소: 표준 기반 구현은 특정 공격으로부터 보호합니다. HttpOnly 쿠키는 JavaScript 접근을 방지합니다. SameSite 속성은 Cross-Site Request Forgery (CSRF) 공격을 차단합니다. FIDO2 토큰은 암호학적 출처 바인딩을 통해 피싱 저항성을 달성합니다.
그러나 이러한 이점에는 상충 관계가 따릅니다. 확장성과 유연성을 가능하게 하는 동일한 아키텍처 결정이 보안 팀이 해결해야 할 과제도 함께 도입합니다.
인증 토큰의 과제와 한계
토큰 기반 인증은 신중한 아키텍처 계획이 필요한 특정 운영 및 보안 과제를 도입합니다.
- 토큰 폐기의 복잡성: 확장성 이점을 제공하는 상태 비저장 특성은 즉각적인 액세스 종료에 대한 과제를 만듭니다. 상태 비저장 토큰은 만료 시점까지 유효하므로, 리프레시 오버헤드를 증가시키는 짧은 수명, 상태 비저장 이점을 상쇄하는 토큰 블랙리스트 인프라, 또는 폐기 지연 구간의 수용 중 하나가 필요합니다.
- 토큰 수명 관리의 상충 관계: 짧은 액세스 토큰 수명은 침해 시 잠재적 피해를 제한하지만 지속적인 리프레시 토큰 교환을 요구합니다. 긴 수명은 사용자 경험을 개선하지만 토큰이 탈취될 경우 더 큰 노출 구간을 만듭니다.
- 플랫폼 전반의 안전한 토큰 저장: 페이지에서 실행되는 모든 스크립트는 localStorage와 sessionStorage를 읽을 수 있으므로, 단 하나의 Cross-Site Scripting (XSS) 취약점만으로도 둘 중 어느 쪽이든 유효한 토큰 목록으로 바뀝니다. 널리 채택된 하이브리드 접근 방식은 리프레시 토큰을 HttpOnly 쿠키에 저장하고, 액세스 토큰은 메모리에 유지하며, 리프레시 엔드포인트에 CSRF 검사를 적용합니다. 메모리에 있는 액세스 토큰은 호스트가 침해된 경우 메모리 덤프에 여전히 노출되며, 이것이 바로 엔드포인트 보안이 필요한 이유입니다. 모바일 애플리케이션에는 플랫폼별 저장소가 필요합니다. iOS Keychain은 토큰을 직접 보관하고, Android는 Android Keystore에 보관된 키로 이를 암호화합니다. 서버 간 통신은 HashiCorp Vault 또는 AWS Secrets Manager와 같은 시크릿 관리 시스템에 속해야 합니다.
- 키 로테이션 및 암호화 관리: 운영 환경에서의 키 로테이션은 조정 복잡성을 초래합니다. 조직은 로테이션 기간 동안 여러 개의 유효한 서명 키를 유지하고, 분산 서비스 전반에서 로테이션을 조정하며, 키 식별자(kid) 검증을 올바르게 처리해야 합니다.
이러한 구현 과제는 공격자가 엔터프라이즈 환경에서 적극적으로 악용하는 특정 취약점을 만들어냅니다.
일반적인 인증 토큰 구현 실수
대부분의 인증 토큰 침해는 암호학적 결함이 아니라 구현 실수에서 비롯됩니다. 이러한 일반적인 오류를 이해하면 보안 팀이 강화 작업의 우선순위를 정하는 데 도움이 됩니다.
- 안전하지 않은 클라이언트 측 저장소: 인증 토큰을 브라우저 localStorage 또는 sessionStorage에 저장하는 것은 가장 흔한 구현 실수 중 하나입니다. 페이지 컨텍스트 내에서 실행되는 모든 JavaScript 코드는 인증 토큰에 직접 접근하고 이를 유출할 수 있으므로, 즉시 XSS 공격에 취약해집니다.
- 서명 검증 실패: JWT 서명을 올바르게 검증하지 않으면 악용 가능한 인증 우회 취약점이 발생합니다. 알고리즘 혼동 공격은 알고리즘 헤더를 RS256(비대칭)에서 HS256(대칭)으로 조작한 뒤 공개 키를 HMAC 시크릿으로 사용해 토큰에 서명합니다. 취약한 시스템은 이러한 수정된 토큰을 수용하여 권한 상승을 허용합니다. 이 취약점은 CVE-2024-54150에서 CVSS 9.1 CRITICAL 심각도 등급으로 문서화되었습니다. 일부 구현은 "alg: none"을 지정한 토큰을 수용하여 사실상 서명되지 않은 토큰을 유효한 것으로 처리합니다.
- 과도한 토큰 수명: 토큰 수명을 지나치게 길게 설정하면 지속적인 보안 위험이 발생합니다. 장수명 토큰은 공격자에게 더 긴 기회의 창을 제공합니다. XSS 또는 중간자 공격을 통해 한 번 침해되면, 과도한 수명의 토큰은 몇 분이 아니라 며칠 또는 몇 주 동안 무단 액세스를 가능하게 합니다.
- 누락된 토큰 폐기 메커니즘: 토큰 폐기 기능의 부재는 중대한 아키텍처 공백입니다. Azure AD와 같은 SSO 구현에서 사용되는 Primary Refresh Tokens (PRTs)의 침해는 특히 문제가 됩니다. 폐기 메커니즘이 없으면 조직은 침해된 세션을 실시간으로 종료할 수 없고, 자연 만료에 의존할 수밖에 없습니다.
- 안전하지 않은 키 관리: 키 관리 실패는 시스템 전반의 취약점을 만듭니다. 키 검색 메커니즘의 SQL injection 취약점은 애플리케이션이 kid 매개변수를 통해 JWT 키를 가져오기 위해 취약한 SQL 쿼리를 사용할 때 서명 키를 노출시킬 수 있습니다. JWT 페이로드에 민감한 정보를 저장하면 불필요한 데이터 노출이 발생하는데, JWT 클레임은 base64로만 인코딩될 뿐(암호화되지 않음) 토큰에 접근할 수 있는 누구나 쉽게 읽을 수 있기 때문입니다.
이러한 실패에는 이름과 날짜가 있습니다. 2022년 4월, 공격자는 Heroku and Travis CI에서 탈취한 OAuth 토큰을 사용해 npm을 포함한 수십 개 조직의 비공개 리포지토리를 다운로드했습니다. 이 페이지 상단에서 설명한 Okta 세션 토큰 탈취도 같은 방식으로 작동했습니다. 유효한 토큰이 잘못된 당사자에 의해 제시되었고, 아무 의심 없이 수용되었습니다.
이러한 실패는 모두 예방할 수 있으며, 필요한 통제는 이미 문서화되어 있습니다. 확립된 표준에 기반한 심층 방어는 공격자가 기대하는 격차를 메웁니다.
인증 토큰 모범 사례
인증 토큰을 보호하려면 NIST SP 800-63B-4, OWASP, IETF 사양과 같은 권위 있는 보안 표준에 기반한 심층 방어 전략을 구현해야 합니다.
- HttpOnly 및 Secure 쿠키 배포: HttpOnly 쿠키에 저장된 리프레시 토큰과 메모리에 유지되는 액세스 토큰을 결합하십시오. 쿠키 내용에 대한 JavaScript 접근을 방지하는 HttpOnly 플래그를 설정하십시오. HTTPS 연결을 통해서만 전송되도록 보장하는 Secure 플래그를 구성하십시오. CSRF 보호를 위해 SameSite 속성을 구현하십시오.
- 로테이션이 적용된 단수명 액세스 토큰 구현: 위험 허용 수준에 따라 액세스 토큰 수명을 구성하십시오. 토큰 로테이션은 사용할 때마다 새로운 리프레시 토큰을 생성하여 재생 공격을 방지합니다. 발급된 모든 리프레시 토큰을 jti 클레임으로 추적하고, 성공적인 로테이션 직후 이전 토큰을 즉시 무효화하십시오.
- 엄격한 서명 검증 강제: 헤더에 "alg: none"이 지정된 토큰을 명시적으로 거부하십시오. 서명 알고리즘이 예상된 유형과 일치하는지 검증하여 RSA/HMAC 혼동 공격을 방지하십시오. 키 검색에는 매개변수화된 쿼리를 사용해 SQL injection을 방지하십시오.
- 토큰 바인딩 배포: Conditional Access 정책을 구성해 토큰 바인딩을 강제하고, Trusted Platform Module (TPM) 또는 Secure Enclave 통합을 통해 토큰이 원래 발급된 디바이스 외부에서 작동하지 못하도록 보장하십시오.
- 폐기 인프라 구현: jti 클레임을 사용한 데이터베이스 기반 토큰 패밀리 추적을 구축하십시오. 세션 폐기를 위한 관리 인터페이스를 만들고, 사용자가 침해를 의심할 때 모든 세션을 폐기할 수 있는 "모든 위치에서 로그아웃" 기능을 배포하십시오.
이러한 모범 사례를 갖추더라도 정교한 공격자는 계속해서 토큰을 침해할 방법을 찾습니다. 예방이 버티지 못할 때 중요한 것은 오용을 얼마나 빨리 발견하고 얼마나 빨리 대응할 수 있는가입니다.
SentinelOne이 신원 기반 공격을 탐지하는 방법
Singularity™ Platform은 엔드포인트, 클라우드 워크로드, 신원 인프라 전반에 걸쳐 자율적인 탐지 및 대응을 제공합니다. 2024 MITRE ATT&CK Evaluations: Enterprise에서 SentinelOne은 평가된 모든 벤더의 중앙값보다 88% 적은 경고로 100% 탐지를 기록했으며, 이는 분석가가 처리할 수 있는 경고 큐와 포기하게 되는 경고 큐의 차이입니다. Purple AI™는 조사 자체를 가속화합니다. 분석가는 자연어로 질문하고 맥락이 포함된 경고 요약을 반환받으며, 위협 헌팅 속도는 최대 80% 빨라집니다.
Singularity Identity는 Active Directory와 Entra ID를 신원 위협으로부터 방어합니다. 이 솔루션의 탐지는 해당 환경을 직접 겨냥하는 자격 증명 공격, 즉 측면 이동과 권한 상승을 위한 탈취 및 위조 Kerberos 티켓 사용을 포함한 공격에 대해 작동합니다. Storyline™ 기술은 공격이 전개되는 과정을 재구성하고 인증 이벤트를 엔드포인트 동작과 연관 분석합니다. 단일 경고가 아니라 전체 체인을 볼 수 있습니다. 탐지가 발생하면 자율 대응이 위협을 차단하고 호스트를 격리하며, 랜섬웨어가 암호화를 완료하기 전에 1-Click rollback으로 피해를 되돌립니다.
SentinelOne에 데모 요청하기를 통해 귀사의 환경에서 신원 기반 탐지가 어떻게 작동하는지 확인해 보십시오.
하이브리드 환경 전반에 걸쳐 실시간 아이덴티티 보호와 엔드투엔드 가시성을 확보하여 노출을 탐지하고, 자격 증명 오용을 차단하며, 아이덴티티 위험을 감소시킵니다.
핵심 요점
도입부의 도쿄 공격 시나리오를 기억하십니까? 이는 탈취된 토큰이 비밀번호나 MFA 프롬프트를 전혀 건드리지 않고 인증을 우회할 때 발생합니다. 잘못 구성된 토큰은 실제 노출을 만들지만, 그럼에도 토큰은 여전히 필수적입니다. 각 유형에는 역할이 있습니다. JWT는 상태 비저장 마이크로서비스용, OAuth 2.0은 API 권한 부여용, SAML은 엔터프라이즈 SSO용, FIDO2는 피싱 저항형 인증용입니다. 이들 모두는 부주의하게 구현될 때 공격 벡터가 됩니다.
수정 목록은 짧습니다. 리프레시 토큰은 HttpOnly 쿠키에 저장하고, 액세스 토큰은 메모리에 유지하며, 서명은 엄격하게 검증하고, 리프레시할 때마다 로테이션하십시오. 이 페이지의 대부분의 실패는 이 중 하나를 하지 않았기 때문이며, 여기에 구축보다 미루기 쉬운 두 가지가 더해집니다. 바로 폐기 인프라와 키 관리입니다.
XDR과 identity threat detection and response (ITDR)를 추가하면 잘못된 손에 들어간 토큰이 6개월 뒤 감사 결과로 드러나는 대신 탐지로 표면화됩니다. CVE-2024-54150와 MITRE ATT&CK's October 2024 update에서 추적된 8개의 국가 지원 그룹은 토큰 악용이 현재 진행형의 활발한 위협임을 보여줍니다. 이를 막는 통제는 이미 존재하며, 이를 배포하는 것은 귀하의 몫입니다.
FAQ
인증 토큰은 사용자 이름과 비밀번호를 반복적으로 전송할 필요 없이 엔터프라이즈 시스템에 대한 사용자의 신원을 검증하는 암호화 자격 증명입니다. 애플리케이션에 로그인하면 서버는 인증이 성공적으로 완료되었음을 증명하는 토큰을 발급합니다.
사용자의 디바이스는 이후의 각 요청과 함께 이 토큰을 제시하며, 이를 통해 서버는 두 번째 로그인 없이 사용자의 신원을 검증할 수 있습니다. 일반적인 형식에는 JSON Web Tokens (JWTs), OAuth 2.0 토큰, SAML 어설션, FIDO2 토큰이 포함됩니다.
액세스 토큰은 보호된 리소스에 접근하기 위한 수명이 짧은 자격 증명을 제공하며, 일반적으로 NIST 권고에 따라 몇 분 내에 만료됩니다. 리프레시 토큰은 현재 토큰이 만료될 때 반복적인 인증을 요구하지 않고 새로운 액세스 토큰을 획득할 수 있게 하며, 일반적으로 며칠에서 몇 주 동안 유효합니다.
이 이중 토큰 접근 방식은 짧은 액세스 토큰 수명을 통한 보안과 사용자 경험의 균형을 맞춥니다. 토큰 로테이션은 사용할 때마다 새로운 리프레시 토큰을 생성하고 이전 토큰을 무효화하여 재생 공격을 방지합니다.
공격자는 XSS 공격을 통해 localStorage에서 토큰을 추출하고, 전송을 가로채는 중간자 공격, 손상된 엔드포인트에서의 메모리 덤프, CI/CD 파이프라인 악용, 그리고 CSRF 세션 하이재킹을 통해 토큰을 탈취합니다.
APT28, APT29, APT41, Kimsuky, MuddyWater, OilRig, Sandworm Team, Turla를 포함한 8개의 국가 지원 그룹이 2024년에 토큰 공격 역량을 업데이트했습니다. 보호를 위해서는 HttpOnly 쿠키, HTTPS를 통한 안전한 전송, 디바이스에 대한 토큰 바인딩, 그리고 비정상적인 사용 패턴을 탐지하는 행위 모니터링이 필요합니다.
JavaScript 액세스와 CSRF 공격을 방지하는 HttpOnly, Secure, SameSite 쿠키에 리프레시 토큰을 저장하세요. 수명이 짧은 액세스 토큰은 localStorage 또는 sessionStorage 대신 메모리에 보관하여 XSS 기반 탈취를 피하세요.
모바일 앱의 경우 iOS Keychain 또는 Android KeyStore를 사용하세요. 서버 통신의 경우 환경 변수나 구성 파일 대신 HashiCorp Vault 또는 AWS Secrets Manager와 같은 시크릿 관리 시스템을 사용하세요.
JWT에는 토큰에 접근할 수 있는 누구나 읽을 수 있는 base64 인코딩 클레임이 포함됩니다. 민감한 데이터의 경우 RSA-OAEP-256 또는 AES-GCM과 같은 표준을 통해 페이로드 암호화를 제공하는 JWE (JSON Web Encryption)를 사용하세요.
하지만 더 나은 방법은 토큰 페이로드에 민감한 데이터를 절대 포함하지 않는 것입니다. 사용자 ID 및 역할과 같은 비민감 식별자만 저장하세요. 민감한 속성은 백엔드 데이터베이스에 보관하고, 토큰 식별자를 사용해 서버 측에서 이를 조회하세요.
토큰 바인딩은 인증 토큰을 발급된 특정 디바이스에 암호학적으로 연결하여 공격자가 탈취한 토큰을 다른 시스템에서 재사용하지 못하도록 방지합니다. 토큰은 암호학적 증명을 통해 디바이스의 Trusted Platform Module (TPM) 또는 Secure Enclave에 바인딩됩니다.
토큰이 제시되면 서버는 토큰 서명과 디바이스 바인딩을 모두 검증합니다. Microsoft Conditional Access 및 유사한 엔터프라이즈 ID 관리 솔루션은 높은 보안 수준이 요구되는 환경을 위해 토큰 바인딩을 지원합니다.
