ID 토큰 대 액세스 토큰: OpenID Connect의 결정적 차이

By Mirko Peters · 2026-10-28

OpenID Connect에서 ID 토큰과 액세스 토큰의 핵심 차이를 살펴보고, 두 토큰을 혼동하면 왜 심각한 보안 결함으로 이어지는지 알아봅니다.

Automatically translated with AI from the original post. Read the English original

최신 인증 환경에서 일하는 개발자와 IT 관리자에게 ID 토큰과 액세스 토큰의 차이를 이해하는 일은 매우 중요합니다. OAuth 2.0은 권한을 처리하고, OpenID Connect는 사용자 신원을 확인하기 위해 ID 토큰을 도입합니다. 이 두 가지 서로 다른 토큰을 혼동하면 클라우드 애플리케이션에 심각한 보안 취약점이 생깁니다.

핵심 요약

• ID 토큰은 사용자의 ID를 증명하고, 액세스 토큰은 권한과 permissions를 부여합니다.
• 이 두 토큰을 혼동하는 것은 자체 개발 애플리케이션 보안에서 가장 흔한 실수입니다.
• OpenID Connect는 OAuth 2.0 프레임워크 위에 신원 확인 계층을 추가합니다.
• 액세스 토큰은 취소할 수 있으므로, 비밀번호를 저장하는 방식보다 안전한 보안 태세를 제공합니다.
• 애플리케이션은 수신한 ID 토큰을 무조건 신뢰하지 않고, 암호화 방식으로 검증해야 합니다.

핵심 딜레마: ID 대 권한 부여

최신 웹 애플리케이션이 발전하면서 개발자들은 사용자가 로그인하는 방식과 같은 사용자가 기본 데이터와 상호 작용하는 방식을 두고 혼란을 겪는 경우가 많습니다. 이러한 혼란의 상당 부분은 ID 영역에서 용어가 겹치는 데서 비롯됩니다. 애플리케이션이 웹 전반으로 빠르게 확장되기 시작했을 때, 단순한 사용자 이름과 암호 조합에만 의존하는 방식은 큰 보안 병목을 만들었습니다. 사용자들은 여러 개의 고유한 자격 증명을 관리하는 데 지쳤고, 그 결과 여러 플랫폼에서 약한 암호를 재사용하는 문제가 생겼습니다.

이 문제의 일부를 해결하기 위해 OAuth 2.0이 등장했습니다. 그러나 OAuth 2.0은 애초에 사용자가 누구인지 답하기 위해 설계되지 않았습니다. 그 목적은 사용자를 대신하여 애플리케이션이 특정 데이터 엔드포인트에 접근할 수 있도록 하는 권한 증명서, 즉 액세스 토큰을 제공하는 것입니다. 액세스 토큰은 애플리케이션이 무엇을 할 수 있는지를 알려 주지만, 토큰을 가진 사람의 신원에 대해서는 전혀 알려 주지 않습니다. 이러한 근본적인 공백 때문에 단일 로그인(SSO) 환경을 구축하려던 기업들은 OAuth에 자체 맞춤형 신원 확인 로직을 덧붙여야 했고, 그 결과 서로 잘 맞지 않는 파편화된 구현이 생겨났습니다.

OpenID Connect는 바로 이 공백을 메우기 위해 인증 전용으로 설계된 표준화된 계층을 도입했습니다. 기존 액세스 토큰과 함께 두 번째 토큰을 사용함으로써, OpenID Connect는 신원의 문제와 권한의 문제를 명확하게 분리합니다. 이 두 개념을 구분해서 생각하는 것이 오늘날 클라우드 애플리케이션을 설계하거나 감사하는 모든 사람에게 가장 중요한 사고의 전환입니다.

ID 토큰의 구조: 내부에 무엇이 들어 있나

사용자가 "Microsoft로 로그인" 버튼을 클릭하면, ID 공급자는 자격 증명을 처리하고 다단계 인증 요구 사항을 수행한 뒤, 최종적으로 ID 토큰과 함께 사용자를 애플리케이션으로 되돌려 보냅니다. 이 토큰은 JSON Web Token(JWT)으로 패키징되며, 보통 JWT라고 줄여 부르고 "조트(jot)"라고 발음합니다. 언뜻 보면 JWT는 점으로 구분된 알아보기 어려운 문자열처럼 보입니다. 하지만 디코딩하고 나면 내부 구조는 놀라울 정도로 단순합니다.

ID 토큰 안에는 각각 뚜렷한 목적을 가진 몇 가지 표준 클레임이 들어 있습니다.

• 발급자(Issuer): 토큰을 생성하고 서명한 특정 ID 공급자(예: Microsoft Entra ID)를 식별합니다.
• 주체(sub): 사용자를 고유하고 변경할 수 없게 식별하는 값입니다. 특히 사용자가 표시 이름이나 이메일 주소를 바꾸더라도 변하지 않도록 설계되어 있습니다.
• 대상(aud): 토큰이 발급된 정확한 애플리케이션을 지정합니다. 덕분에 한 앱용으로 발급된 토큰을 악의적으로 가로채 다른 앱에서 재사용할 수 없습니다.
• 타임스탬프: 토큰이 발급된 시점, 만료되는 시점, 그리고 사용자가 인증을 마친 정확한 순간을 나타냅니다.
• Nonce: 발급된 토큰을 이를 요청한 특정 로그인 세션에 연결하는 보안 접수 번호 역할을 합니다. 이를 통해 재전송 공격(replay attack)을 효과적으로 차단합니다.

가장 중요한 점은 전체 패키지가 제공자의 개인 키로 서명된다는 것입니다. 수신 애플리케이션은 제공자가 공개한 짝이 되는 공개 키로 이 서명을 검증합니다. 이러한 암호학적 검증이 없다면 ID 토큰은 당사자 사이에서 전달되는 검증되지 않은 메모에 지나지 않습니다.

인증을 접근 권한으로 착각하는 위험

애플리케이션 개발에서 가장 위험한 안티 패턴 중 하나는 ID 토큰을 권한 키로 취급하는 것입니다. ID 토큰은 사용자가 특정 조직에 속한 John Doe라는 사실을 확인해 주기 때문에, 경험이 부족한 개발자는 이 확인 결과를 관리자 권한이나 제한 없는 데이터베이스 접근을 부여하는 근거로 잘못 사용하기도 합니다. 이는 아키텍처를 근본적으로 잘못 이해한 것입니다.

ID 토큰은 현관 앞에 누가 서 있는지만 알려줄 뿐, 그 사람이 모든 내부 공간에 들어가도 되는지 또는 특정 관리 버튼을 눌러도 되는지에 대해서는 아무 판단도 하지 않습니다. 권한 부여 로직은 역할 기반 액세스 제어(RBAC) 등의 방식을 사용해 애플리케이션이 별도로 처리해야 합니다. 검증된 신원은 최종 권한 결정이 아니라 출발점으로 삼아야 합니다.

또한 많은 애플리케이션이 적절한 검증 절차 없이 들어온 ID 토큰을 받아들이는 실수를 합니다. 라이브러리가 뒤에서 토큰을 처리했다는 이유만으로 토큰을 무조건 신뢰하면, 시스템이 위조된 데이터에 노출됩니다. 서명을 검증하고, 만료 타임스탬프를 확인하며, 대상(aud) 클레임을 확인하는 것은 보안 태세를 유지하기 위해 반드시 거쳐야 할 단계입니다.

결론

인증과 권한 부여의 경계를 정확히 이해하면 최신 클라우드 아키텍처를 훨씬 명확하게 파악할 수 있습니다. ID 토큰은 키보드 앞에 있는 사람이 누구인지 증명하는 데만 집중하고, 액세스 토큰이 허용되는 작업의 범위를 관리하도록 두면, 개발자는 Microsoft Entra ID와 같은 플랫폼과 연동하는 견고하고 안전한 통합을 구축할 수 있습니다. 이러한 개념에 대한 종합적인 설명을 듣고 Microsoft 생태계에서 최신 로그인 워크플로가 어떻게 작동하는지 알아보려면 전체 논의를 확인해 보십시오. 전체 에피소드 듣기를 통해 클라우드 인증의 작동 원리를 오늘 더 깊이 알아보십시오!

자주 묻는 질문

ID 토큰을 사용해 API를 호출하거나 보호된 리소스에 액세스할 수 있습니까?

아니요. ID 토큰에는 사용자가 누구인지에 대한 신원 클레임만 들어 있습니다. API를 호출하거나 보호된 리소스에 액세스하려면 애플리케이션이 OAuth 2.0을 통해 발급된 액세스 토큰을 사용해야 합니다.

OpenID Connect와 OAuth 2.0이 별도의 토큰을 사용하는 이유는 무엇입니까?

신원과 권한 부여를 분리하면 애플리케이션이 로그인하는 사용자를 확인하면서도, 해당 애플리케이션에 사용자의 기본 데이터나 리소스를 마음대로 조작할 수 있는 무제한 권한을 부여하지 않을 수 있습니다.

애플리케이션이 서명을 확인하지 않고 ID 토큰을 받아들이면 어떤 일이 발생합니까?

서명 검증을 생략하면 애플리케이션이 위조된 토큰에 취약해집니다. 누구든 유효한 사용자인 것처럼 주장하는 임의의 문자열을 만들어 낼 수 있기 때문입니다.

'nonce' 값은 토큰 교환 과정의 어디에 들어갑니까?

nonce는 로그인 흐름이 시작될 때 생성되는 무작위 문자열로, ID 토큰 안에 포함됩니다. 애플리케이션은 이를 통해 재전송 공격을 방지할 수 있습니다.