OAuth 프레임워크 종합 분석: 프로토콜, Grant 유형 및 최신 보안 모범 사례
섹션 1: 위임된 권한 부여의 기초: OAuth 2.0 이해하기
이 섹션에서는 OAuth 프레임워크 전체의 개념적 기반을 구축한다. 단순히 정의를 나열하는 것을 넘어, OAuth가 해결하고자 했던 근본적인 문제, 프레임워크 내 행위자들의 역할, 그리고 전체 보고서의 토대가 되는 권한 부여와 인증의 핵심적인 차이점을 심층적으로 분석한다.
1.1 핵심 문제: 패스워드 안티패턴과 위임의 필요성
OAuth 이전 시대에는 제3자 애플리케이션(예: 'A' 서비스)이 다른 서비스(예: 네이버, 구글)에 있는 사용자의 데이터에 접근하기 위해 해당 서비스의 아이디와 비밀번호를 직접 사용자에게 요구하는 것이 일반적인 패턴이었다. 이 방식은 심각한 보안 취약점을 내포하고 있었다. 사용자의 민감한 자격 증명을 제3자 애플리케이션이 직접 저장해야 했으므로, 해당 애플리케이션은 공격자들에게 매우 가치 있는 표적이 되었다. 서비스 제공자(예: 네이버)는 제3자 애플리케이션을 신뢰할 수 없었으며, 사용자는 접근 범위를 제한하거나 비밀번호를 변경하지 않고는 접근 권한을 취소할 방법이 없었다.
이러한 '패스워드 안티패턴'을 해결하기 위해 등장한 것이 바로 위임된 권한 부여(Delegated Authorization) 메커니즘인 OAuth이다. 근본적인 문제는 단순히 비밀번호를 공유하는 행위를 넘어, 정보 보안의 기본 원칙인 '최소 권한 원칙(Principle of Least Privilege)'을 위배한다는 점에 있다. 애플리케이션에 비밀번호를 제공하는 것은 해당 애플리케이션에 사용자의 모든 권한을 부여하는 것과 같다. OAuth는 scope라는 개념을 도입하여 이 문제를 직접적으로 해결했다.
scope는 리소스 소유자(사용자)가 클라이언트(제3자 애플리케이션)에게 포괄적인 접근 권한 대신 "연락처 읽기"나 "타임라인에 글쓰기"와 같은 특정 행위만을 수행할 수 있도록 허용하는 기술적 구현체이다. 이는 OAuth가 단순한 로그인 도구가 아니라, 세분화되고 취소 가능한 권한을 관리하고 강제하기 위한 근본적인 프레임워크임을 명확히 보여준다.
1.2 주요 행위자: 네 가지 핵심 역할 해부
OAuth 2.0 프레임워크는 네 가지 주요 역할을 정의하며, 이들의 상호작용을 통해 권한 부여 흐름이 완성된다.
리소스 소유자 (Resource Owner): 데이터의 소유자이자 접근 권한을 부여하는 최종 사용자이다. 예를 들어, 자신의 구글 계정을 사용하는 사람을 의미한다.
클라이언트 (Client): 사용자의 데이터에 접근을 요청하는 제3자 애플리케이션이다. 예를 들어, 사용자의 구글 포토에 접근하여 사진을 인화하려는 서비스를 말한다.
리소스 서버 (Resource Server): 사용자의 데이터나 리소스를 호스팅하는 서버이다. 예를 들어, 구글 포토 API 서버가 이에 해당한다.
권한 부여 서버 (Authorization Server): 리소스 소유자를 인증하고, 동의를 얻어 클라이언트에게 액세스 토큰(Access Token)을 발급하는 서버이다. 구글의 로그인 및 동의 화면을 제공하는 서버가 대표적인 예이다.
일부 자료에서는 설명을 단순화하기 위해 권한 부여 서버와 리소스 서버를 하나로 묶어 설명하기도 하지만 , 아키텍처 관점에서는 이 둘의 책임이 명확히 분리되어 있음을 이해하는 것이 매우 중요하다. 권한 부여 서버는 신원 확인과 동의 처리를 담당하는 반면, 리소스 서버는 제공된 토큰을 기반으로 데이터 접근 제어를 담당한다. 이러한 '관심사의 분리(Separation of Concerns)'는 OAuth 2.0의 핵심적인 설계 특징 중 하나이다.
1.3 결정적 차이: 인증(Authentication)과 인가(Authorization)
OAuth를 정확히 이해하기 위해서는 인증과 인가의 차이를 명확히 구분해야 한다.
인증 (Authentication, AuthN): 사용자가 누구인지 증명하는 과정이다. "당신은 누구입니까?"라는 질문에 답하는 과정으로, 신원을 확인하는 행위이다. Microsoft는 이를 위해 OpenID Connect(OIDC)를 사용한다.
인가 (Authorization, AuthZ): 인증된 사용자가 무엇을 할 수 있는지 결정하는 과정이다. "당신은 무엇을 할 수 있습니까?"라는 질문에 답하는 과정으로, 권한을 부여하는 행위이다. Microsoft는 이를 위해 OAuth 2.0을 사용한다.
핵심 명세인 RFC 6749에 정의된 바와 같이, OAuth 2.0은 엄밀히 말해 인가 프레임워크이지, 인증 프로토콜이 아니다. 이는 클라이언트가 리소스에 접근할 수 있는 권한(액세스 토큰)을 어떻게 획득하는지를 표준화한다. 하지만 OAuth 2.0 자체는 클라이언트가 그 권한을 부여한 사용자의 신원 정보를 어떻게 표준화된 방식으로 알 수 있는지에 대해서는 정의하지 않는다.
이 지점에서 OAuth 2.0의 "인증 공백(Authentication Gap)"이 발생한다. 순수 OAuth 2.0만을 사용하여 "구글로 로그인" 기능을 구현하는 개발자는 액세스 토큰을 받게 된다. 이 토큰은 구글 API(예: 사용자 프로필 정보 API)를 호출하는 데 사용될 수 있다. 그러나 액세스 토큰 자체에는 표준화된 사용자 신원 정보가 포함되어 있지 않다. 클라이언트는 해당 정보를 얻기 위해 별도의 특정 엔드포인트(예: /userinfo 엔드포인트)를 호출해야 하며, 이 과정은 OAuth 2.0에 의해 표준화되지 않았다. 이러한 인증 공백은 OAuth 2.0 위에 일관되고 상호 운용 가능한 방식으로 신원 확인을 처리할 표준 계층의 필요성을 야기했다. 이 필요를 충족시킨 것이 바로 OAuth 2.0 위에 구축된 신원 계층인 **OpenID Connect (OIDC)**이다. 이 인과 관계는 매우 중요하다. 즉, 순수 인가 프레임워크로서의 OAuth 2.0의 한계가 그것의 인증 파트너인 OIDC의 탄생을 직접적으로 이끌었다. 이 내용은 섹션 4에서 심도 있게 다룰 것이다.
섹션 2: 현대적 표준으로의 진화: OAuth 1.0a 대 OAuth 2.0
이 섹션에서는 복잡하고 암호학적으로 무거웠던 OAuth 1.0a에서 간소화되고 TLS에 의존하는 OAuth 2.0으로의 중요한 전환 과정을 역사적 맥락과 함께 기술적으로 분석한다. 이 진화 과정을 이해하는 것은 현대 표준의 설계 철학과 보안 모델을 파악하는 데 핵심적이다.
2.1 구시대의 표준: OAuth 1.0a의 암호학적 접근 방식
OAuth 1.0a는 모든 API 요청이 복잡한 암호화 기법을 사용하여 개별적으로 서명될 것을 요구했다. 각 메시지의 무결성과 진위성을 증명하기 위해 디지털 서명에 기반을 두었으며 , 이로 인해 보안이 메시지 수준에서 처리되어 전송 계층에 독립적(Transport-independent)이었다.
이론적으로 이 접근 방식은 강력하고 안전했다. 서명된 메시지는 그 출처에 귀속되며 변조될 수 없었다. 하지만 개발자 입장에서 이를 올바르게 구현하는 것은 매우 어려웠다. 서명을 생성하고 검증하는 과정의 복잡성은 OAuth 1.0a 채택의 주요 장벽으로 작용했다.
2.2 새로운 표준: OAuth 2.0의 단순성과 확장성에 대한 집중
OAuth 2.0은 1.0과의 하위 호환성이 없는 완전한 재작성(rewrite)의 결과물이다. 이는 개발자들이 더 쉽게 사용할 수 있도록 설계되었으며 , 모든 API 호출에 대해 복잡한 클라이언트 측 암호화 서명을 생성할 필요성을 제거했다. 대신, 통신의 보안을 위해 HTTPS/TLS에 의존하여 당사자 간의 통신 채널 자체를 보호한다. 또한, 토큰의 소유 자체가 접근 권한을 증명하는 베어러 토큰(Bearer Token) 개념을 중심으로 한다.
이러한 변화는 OAuth의 접근성을 극적으로 향상시켰고, 구글, 페이스북, 마이크로소프트와 같은 주요 기업들이 이를 채택하며 광범위하게 확산되는 결과를 낳았다. 또한, OAuth 1.0의 한계였던 웹 브라우저 기반이 아닌 애플리케이션(예: 모바일, 데스크톱)을 포함한 다양한 클라이언트 유형을 지원하기 위해 여러 "Grant 유형(grant types)"을 도입했다.
2.3 보안의 트레이드오프: 패러다임의 전환
1.0에서 2.0으로의 진화는 단순한 '업그레이드'가 아니라 전략적인 트레이드오프의 결과였다. OAuth 1.0a의 암호학적 복잡성은 개발자들에게 높은 진입 장벽이었고, 이는 광범위한 채택을 저해하는 원인이었다. 이에 대응하여 IETF는 주요 산업 플레이어들의 의견을 수렴하여 , 메시지 수준의 보안을 전송 계층 보안(TLS)으로 위임함으로써 OAuth 2.0을 근본적으로 단순화했다.
이러한 단순화는 진입 장벽을 극적으로 낮추어 오늘날 우리가 보는 OAuth 2.0의 보편적인 채택을 이끌었고, API 인가의 사실상 표준(de facto standard)이 되었다. 하지만 이 설계 선택은 보안의 책임을 다른 곳으로 이전시키는 결과를 낳았다. 이제 OAuth 2.0 흐름의 전체 보안은
TLS의 정확하고 견고한 구현에 전적으로 의존하게 되었다. TLS 구성의 사소한 약점(예: 부적절한 인증서 검증, 취약한 암호화 스위트 사용)은 공격자가 중간자 공격(Man-in-the-Middle, MitM)을 통해 베어러 토큰을 탈취할 수 있게 하므로 전체 흐름을 위태롭게 할 수 있다.
결론적으로, 이 진화는 프로토콜 수준의 복잡성을 인프라 수준의 의존성과 맞바꾼 것이다. 이로 인해 OAuth 2.0은 "다루기는 더 쉬워졌지만, 안전하게 구축하기는 훨씬 더 어려워졌다"는 평가를 받게 되었다.
섹션 3: OAuth 2.0 Grant 유형의 세분화된 분석
이 섹션은 "OAuth 종류"에 대한 사용자의 질문에 직접적으로 답하는 보고서의 핵심이다. 각 Grant 유형(흐름)의 작동 방식, 주요 대상, 그리고 보안 프로필을 상세히 분석한다. 이 흐름들의 기초 참조 문서는 공식 명세인 RFC 6749이다.
3.1 황금 표준: Authorization Code Grant
이 흐름은 가장 보편적이고 안전한 방식으로, OAuth 2.0의 기본으로 간주된다. 이는 client_secret을 안전하게 저장할 수 있는 기밀 클라이언트(confidential clients), 예를 들어 서버 사이드 웹 애플리케이션을 위해 설계되었다.
작동 방식
1사용자는 response_type=code 파라미터와 함께 권한 부여 서버로 리디렉션된다.
사용자는 권한 부여 서버에서 인증하고 요청된 권한에 동의한다.
권한 부여 서버는 사용자를 클라이언트의 리디렉션 URI로 다시 보내면서, URL에 수명이 짧고 일회용인 **인가 코드(Authorization Code)**를 포함시킨다.
클라이언트의 백엔드 서버는 이 인가 코드를 받아, 자신의 client_id 및 client_secret과 함께 권한 부여 서버의 토큰 엔드포인트로 안전한 서버 대 서버 직접 호출을 수행한다. 이를 통해 최종적으로 액세스 토큰(및 선택적으로 리프레시 토큰)을 교환받는다.
보안적 근거
이 방식의 핵심적인 보안 특징은 민감한 정보인 액세스 토큰이 사용자의 브라우저(user-agent)에 절대 노출되지 않는다는 점이다. 토큰은 클라이언트의 백엔드 서버로 보안 채널을 통해 직접 전송되므로, 브라우저 기록, 리퍼러 헤더, 또는 악성 스크립트를 통한 유출 위험을 근본적으로 완화한다.
3.2 공개 클라이언트를 위한 현대적 강화: Authorization Code with PKCE
이 섹션은 현대 애플리케이션을 위한 결정적인 진화 과정을 다룬다. 공개 클라이언트(public clients), 즉 단일 페이지 애플리케이션(SPA)이나 네이티브 모바일/데스크톱 앱은 client_secret을 안전하게 저장할 수 없다. 이러한 환경에서는 Authorization Code Grant 단독으로는 취약하다. RFC 7636에 정의된 **PKCE(Proof Key for Code Exchange)**는 공개 클라이언트를 위해 이 흐름을 안전하게 만드는 확장 기술이다.
PKCE가 해결하는 취약점: 인가 코드 탈취 공격
모바일 운영체제에서는 여러 앱이 동일한 커스텀 URL 스킴을 처리하도록 등록할 수 있다. 악성 앱이 합법적인 앱과 동일한 리디렉션 URI를 등록한 경우, 권한 부여 서버가 인가 코드를 담아 리디렉션할 때 운영체제는 사용자에게 어떤 앱으로 열지 묻거나, 악성 앱이 리디렉션을 가로챌 수 있다. 공격자가 이 인가 코드를 탈취하면, 이를 사용하여 액세스 토큰을 발급받아 사용자의 리소스에 접근할 수 있게 된다.
PKCE 작동 방식
(리디렉션 전) 합법적인 클라이언트 앱은 code_verifier라는 임의의 고엔트로피 문자열을 생성한다. 그리고 이 code_verifier를 해시(일반적으로 SHA256)하여 code_challenge를 생성한다.
(인가 요청) 클라이언트는 표준 인가 요청에 code_challenge와 code_challenge_method(예: "S256")를 포함하여 권한 부여 서버로 전송한다. 권한 부여 서버는 이 code_challenge를 저장한다.
(토큰 교환) 클라이언트가 인가 코드를 액세스 토큰으로 교환할 때, 요청에 반드시 원본 비밀값인 code_verifier를 포함해야 한다.
(서버 측 검증) 권한 부여 서버는 전달받은 code_verifier를 동일한 해시 알고리즘으로 변환하여 이전에 저장했던 code_challenge와 비교한다. 두 값이 일치하면, 토큰을 요청하는 클라이언트가 인가 흐름을 시작한 클라이언트와 동일함이 증명되므로 토큰을 발급한다. 일치하지 않으면 요청은 거부된다.
PKCE는 원래 client_secret을 사용할 수 없는 공개 클라이언트를 보호하기 위해 설계되었다. 그러나 보안 커뮤니티는 PKCE가 기밀 클라이언트의 경우에도 인가 코드 주입 공격을 방어하고 CSRF(Cross-Site Request Forgery) 방어 체계를 강화하는 부가적인 이점을 제공한다는 것을 발견했다. 이는 최소한의 비용으로 추가적인 보안 계층을 제공한다. 이러한 이점은 PKCE가 모든 클라이언트에 대해 의무화되어야 한다는 강력한 결론으로 이어졌다. 실제로 'OAuth 2.0 보안 모범 사례(BCP)' 문서와 곧 발표될
OAuth 2.1 명세는 Authorization Code Grant를 사용하는 모든 클라이언트(기밀 클라이언트 포함)에 대해 PKCE 사용을 의무화하고 있다. 특정 사용 사례를 위한 확장에서 핵심 흐름의 필수 구성 요소로 발전한 PKCE의 여정은, 성공적인 보안 강화 기술이 결국 기본 표준에 흡수되어 기본적으로 더 안전한(secure-by-default) 생태계를 구축하는 보안 프로토콜 진화의 핵심적인 경향을 보여준다.
3.3 머신 대 머신 통신의 주역: Client Credentials Grant
이 Grant 유형은 최종 사용자의 개입이 없는 비대화형, 즉 머신 대 머신(Machine-to-Machine, M2M) 통신에 사용된다. 백엔드 서비스, 데몬, CLI, 또는 API와 통신하는 IoT 장치 등이 대표적인 예이다. 이는 때때로 "two-legged OAuth"라고도 불린다.
작동 방식
클라이언트(머신/서비스)는 토큰 엔드포인트로 단일 POST 요청을 직접 보낸다.
요청 본문에는 grant_type=client_credentials, 그리고 자신의 client_id와 client_secret이 포함된다.
권한 부여 서버는 클라이언트의 자격 증명을 검증하고, 유효할 경우 직접 액세스 토큰을 반환한다.
보안적 근거
이 흐름은 사용자 상호작용을 완전히 우회하기 때문에 매우 간단하다. 여기서 인증되는 '신원'은 클라이언트 애플리케이션 그 자체이다. 권한은 관리자에 의해 접근 제어 목록(ACL)이나 사전 구성된 역할을 통해 애플리케이션에 직접 부여된다.
client_secret은 유일한 자격 증명이므로 반드시 안전하게 보관되어야 한다.
3.4 레거시 및 폐기된 흐름: 보안적 부검
OAuth 2.0의 초기에는 편의성을 위해 특정 흐름들이 만들어졌다. 특히 자바스크립트 앱을 위한 Implicit Grant와 레거시 시스템 마이그레이션을 위한 ROPC(Resource Owner Password Credentials) Grant가 그러했다. 그러나 이들의 공식적인 폐기는 단순한 기술 업데이트가 아니라, 전체 생태계의 보안 성숙도를 보여주는 중요한 이정표이다. 이는 커뮤니티가 결함 있는 편의성보다 견고하고 기본적으로 안전한 패턴(예: PKCE를 사용한 Authorization Code Grant)을 우선시하며, 불안정한 레거시 옵션을 적극적으로 제거하는 성숙한 단계에 이르렀음을 의미한다.
Implicit Grant의 취약점: 이 흐름은 사용자 동의 후 액세스 토큰을 URL의 프래그먼트(#) 부분에 담아 직접 반환했다. 프래그먼트는 서버로 전송되지 않지만, 페이지의 자바스크립트에서 접근 가능하며 브라우저 기록, 리퍼러 헤더, 악성 스크립트를 통해 유출될 수 있어 매우 불안전하다. 초기의 존재 이유였던 구형 브라우저의 CORS 지원 부재는 더 이상 유효하지 않다.
ROPC Grant의 안티패턴: 이 Grant는 클라이언트 애플리케이션이 사용자의 실제 아이디와 비밀번호를 직접 수집하여 토큰으로 교환하도록 요구했다. 이는 자격 증명을 공유하지 않고 위임한다는 OAuth의 핵심 원칙을 완전히 위배하는 행위이다. 자격 증명을 클라이언트에 노출시키고, 다중 인증(MFA)을 불가능하게 하며, 공격 표면을 극도로 넓히는 심각한 문제를 안고 있다.
결과적으로, 'OAuth 2.0 보안 모범 사례'와 차기 OAuth 2.1 명세는 이 두 흐름을 공식적으로 폐기하고 사용을 금지했다.
섹션 4: 인가를 넘어서: OpenID Connect(OIDC)를 통한 인증
이 섹션은 OAuth와 OIDC 사이의 흔한 혼동을 명확히 해결한다. OIDC를 OAuth 2.0 인가 프레임워크 위에 구축된 필수적인 신원 계층으로 설명하고, 두 프로토콜이 어떻게 상호 보완적으로 작동하는지 분석한다.
4.1 두 토큰 이야기: ID 토큰 대 액세스 토큰
OIDC는 **ID 토큰(ID Token)**이라는 새로운 결과물을 도입하며, 이는 OAuth 2.0이 제공하는 **액세스 토큰(Access Token)**과는 명확히 구분된다. 이 두 토큰의 분리는 인증과 인가의 관심사 분리를 직접적으로 반영하며, "누구인가?"와 "무엇을 할 수 있는가?"라는 두 가지 근본적인 질문에 대한 답을 제공한다.
이러한 토큰의 이중성은 중요한 보안 경계를 형성한다. 잘못된 토큰을 잘못된 목적으로 사용하는 것은 심각한 취약점을 야기한다. 만약 클라이언트가 API에 접근하기 위해 ID 토큰을 리소스 서버로 보낸다면, 이는 보안 모델을 파괴하는 행위이다. 리소스 서버는 해당 토큰이 자신을 위한 것인지(aud 클레임 불일치) 보장할 수 없으며, 부여된 권한(scope)에 대한 정보도 없다. 반대로, 클라이언트는 액세스 토큰을 파싱하여 사용자 정보를 얻으려 해서는 안 된다. 그 형식은 보장되지 않으며 권한 부여 서버와 리소스 서버 간의 구현 세부 사항일 뿐이기 때문이다.
4.2 OIDC가 진정한 싱글 사인온(SSO)을 구현하는 방법
OIDC는 인증 과정과 신원 정보의 형식(ID 토큰)을 표준화한다. 이를 통해 사용자는 구글이나 Okta와 같은 OpenID 제공자로 한 번 로그인한 후, 그 인증된 세션을 사용하여 여러 독립적인 신뢰 당사자(Relying Parties, 즉 클라이언트)에 자격 증명을 다시 입력하지 않고 로그인할 수 있다. 이 표준화된 흐름과 ID 토큰 형식은 연합 신원(Federated Identity) 및 SSO의 핵심인 상호 운용성을 보장한다.
섹션 5: 전략적 구현 및 권장 사항
이 마지막 섹션은 앞선 모든 분석을 종합하여 아키텍트와 개발자를 위한 실행 가능하고 실용적인 지침을 제공한다.
5.1 의사결정 프레임워크: 올바른 Grant 유형 선택하기
Grant 유형의 선택은 임의적이지 않다. 이는 애플리케이션의 아키텍처와 client_secret 같은 비밀 정보를 안전하게 보관할 수 있는 능력에 따라 결정된다. 다음 표는 이러한 선택을 위한 명확한 가이드라인을 제공한다. 이 결정 매트릭스는 복잡한 정보를 종합하여 한눈에 볼 수 있는 참조 자료로 제공함으로써, 독자가 이론을 실제 아키텍처 결정에 적용할 수 있도록 돕는 강력한 도구 역할을 한다.
표 5.1: OAuth 2.0 Grant 유형 선택 매트릭스
| 애플리케이션 아키텍처 | 클라이언트 유형 | 권장 Grant 유형 | 핵심 보안 고려사항 및 근거 | |
| 서버 사이드 웹 앱 (예: Node.js/Express, Java/Spring, Python/Django) | 기밀(Confidential) | Authorization Code with PKCE | 근거: 백엔드는 client_secret을 안전하게 저장할 수 있다. 고전적인 Authorization Code도 가능하지만, 코드 주입 방지 및 CSRF 방어 강화를 위해 이제 PKCE는 모든 클라이언트에 대한 모범 사례(OAuth 2.1에서는 필수)이다. 액세스 토큰은 안전한 서버에 보관되며 브라우저에 노출되지 않는다.
| |
| 단일 페이지 애플리케이션(SPA) (예: React, Angular, Vue.js) | 공개(Public) | Authorization Code with PKCE | 근거: 클라이언트는 전적으로 브라우저에서 실행되므로 client_secret을 안전하게 저장할 수 없다. 공개 클라이언트에 대한 중대한 위협인 인가 코드 탈취 공격을 방지하기 위해 PKCE는 필수적이다. |
Implicit Grant는 금지된다. |
| 네이티브 모바일/데스크톱 앱 (예: iOS, Android, Electron) | 공개(Public) | Authorization Code with PKCE | 근거: SPA와 마찬가지로 client_secret을 안전하게 보관할 수 없는 공개 클라이언트이다. PKCE는 필수적이다. RFC 8252는 피싱 방지 및 인증 세션 공유를 위해 임베디드 웹뷰가 아닌 시스템 브라우저(외부 사용자 에이전트)를 사용할 것을 권장한다.
| |
| 머신 대 머신(M2M) (예: 백엔드 서비스, CLI, 데몬, IoT) | 기밀(Confidential) | Client Credentials | 근거: 사용자 상호작용이 없다. 애플리케이션이 자신의 client_id와 client_secret을 사용하여 스스로를 인증한다. 이 흐름은 이러한 비대화형, 서버 대 서버 사용 사례를 위해 특별히 설계되었다.
| |
| 레거시 / 마이그레이션 시나리오 | 해당 없음 | (없음 - 폐기됨) | Resource Owner Password Credentials (ROPC): 금지됨. 사용자 비밀번호를 직접 처리하여 OAuth의 핵심 원칙을 위반한다. 불안전하며 MFA를 지원하지 않는다. 적절한 대안은 PKCE를 사용한 Authorization Code Grant이다.
| |
5.2 현대적 OAuth 2.0 구현을 위한 보안 모범 사례
다음은 타협할 수 없는 필수 보안 조치들의 통합 체크리스트이다.
항상 HTTPS/TLS 사용: OAuth 2.0의 전체 보안은 여기에 의존한다.
PKCE 의무화: 공개 및 기밀 클라이언트 모두에 대해 Authorization Code Grant와 함께 PKCE를 사용한다.
리디렉션 URI에 대한 정확한 문자열 일치 사용: 공개 리디렉터(Open Redirector) 취약점을 방지한다.
state 파라미터 사용: CSRF 공격을 완화하기 위해 항상 고유하고 예측 불가능한 state 파라미터를 사용한다.
토큰의 정확한 검증: 클라이언트는 ID 토큰을, 리소스 서버는 액세스 토큰을 반드시 검증해야 한다. 여기에는 서명, 발급자(iss), 대상(aud), 만료 시간(exp) 확인이 포함된다.
짧은 수명의 액세스 토큰과 리프레시 토큰 사용: 탈취된 액세스 토큰의 유효 기간을 최소화한다. 사용자를 다시 인증하지 않고 새로운 액세스 토큰을 얻기 위해 (안전하게 저장된) 리프레시 토큰을 사용한다.
5.3 미래: OAuth 2.1 엿보기
OAuth 2.1은 새로운 버전이라기보다는 2.0의 통합 및 강화 버전이다. 이는 모범 사례를 법제화하여 표준을 단순화하는 것을 목표로 한다. OAuth 2.0이 유연한 프레임워크를 지향하며 일부 안전하지 않은 선택지를 포함한 너무 많은 옵션을 제공했던 반면, 지난 10년간 커뮤니티는 어떤 선택이 견고한 보안으로 이어지고 어떤 선택이 취약점으로 이어지는지를 학습했다. OAuth 2.1은 이러한 학습의 정점이다. 새로운 기능을 추가하는 것이 아니라, 나쁜 기능을 제거하고 좋은 기능을 의무화하는 것이다. 이러한 경향은 개발자에게 다양한 안전 수준의 옵션 메뉴를 제공하는 대신, 기본적으로 가장 안전한 구현으로 안내하는 "잘 닦인 길(paved road)"을 지향하는 움직임을 반영한다.
주요 변경 사항은 다음과 같이 요약된다.
PKCE를 사용한 Authorization Code Grant가 유일한 주요 인가 흐름이 된다.
Implicit 및 ROPC Grant가 공식적으로 제거된다.
리디렉션 URI는 정확한 문자열 일치를 사용해야 한다.
쿼리 파라미터를 통한 베어러 토큰 전달이 금지된다.
이러한 변화는 대규모로 안전한 시스템을 구축하는 방법에 대한 성숙한 이해를 바탕으로, 보안을 위한 '위대한 단순화(Great Simplification)'를 추구하는 OAuth 프레임워크의 미래 방향을 명확히 보여준다.
⭐발표자 : 이영청님
OAuth 프레임워크 종합 분석: 프로토콜, Grant 유형 및 최신 보안 모범 사례
섹션 1: 위임된 권한 부여의 기초: OAuth 2.0 이해하기
이 섹션에서는 OAuth 프레임워크 전체의 개념적 기반을 구축한다. 단순히 정의를 나열하는 것을 넘어, OAuth가 해결하고자 했던 근본적인 문제, 프레임워크 내 행위자들의 역할, 그리고 전체 보고서의 토대가 되는 권한 부여와 인증의 핵심적인 차이점을 심층적으로 분석한다.
1.1 핵심 문제: 패스워드 안티패턴과 위임의 필요성
OAuth 이전 시대에는 제3자 애플리케이션(예: 'A' 서비스)이 다른 서비스(예: 네이버, 구글)에 있는 사용자의 데이터에 접근하기 위해 해당 서비스의 아이디와 비밀번호를 직접 사용자에게 요구하는 것이 일반적인 패턴이었다. 이 방식은 심각한 보안 취약점을 내포하고 있었다. 사용자의 민감한 자격 증명을 제3자 애플리케이션이 직접 저장해야 했으므로, 해당 애플리케이션은 공격자들에게 매우 가치 있는 표적이 되었다. 서비스 제공자(예: 네이버)는 제3자 애플리케이션을 신뢰할 수 없었으며, 사용자는 접근 범위를 제한하거나 비밀번호를 변경하지 않고는 접근 권한을 취소할 방법이 없었다.
이러한 '패스워드 안티패턴'을 해결하기 위해 등장한 것이 바로 위임된 권한 부여(Delegated Authorization) 메커니즘인 OAuth이다. 근본적인 문제는 단순히 비밀번호를 공유하는 행위를 넘어, 정보 보안의 기본 원칙인 '최소 권한 원칙(Principle of Least Privilege)'을 위배한다는 점에 있다. 애플리케이션에 비밀번호를 제공하는 것은 해당 애플리케이션에 사용자의 모든 권한을 부여하는 것과 같다. OAuth는 scope라는 개념을 도입하여 이 문제를 직접적으로 해결했다.
scope는 리소스 소유자(사용자)가 클라이언트(제3자 애플리케이션)에게 포괄적인 접근 권한 대신 "연락처 읽기"나 "타임라인에 글쓰기"와 같은 특정 행위만을 수행할 수 있도록 허용하는 기술적 구현체이다. 이는 OAuth가 단순한 로그인 도구가 아니라, 세분화되고 취소 가능한 권한을 관리하고 강제하기 위한 근본적인 프레임워크임을 명확히 보여준다.
1.2 주요 행위자: 네 가지 핵심 역할 해부
OAuth 2.0 프레임워크는 네 가지 주요 역할을 정의하며, 이들의 상호작용을 통해 권한 부여 흐름이 완성된다.
리소스 소유자 (Resource Owner): 데이터의 소유자이자 접근 권한을 부여하는 최종 사용자이다. 예를 들어, 자신의 구글 계정을 사용하는 사람을 의미한다.
클라이언트 (Client): 사용자의 데이터에 접근을 요청하는 제3자 애플리케이션이다. 예를 들어, 사용자의 구글 포토에 접근하여 사진을 인화하려는 서비스를 말한다.
리소스 서버 (Resource Server): 사용자의 데이터나 리소스를 호스팅하는 서버이다. 예를 들어, 구글 포토 API 서버가 이에 해당한다.
권한 부여 서버 (Authorization Server): 리소스 소유자를 인증하고, 동의를 얻어 클라이언트에게 액세스 토큰(Access Token)을 발급하는 서버이다. 구글의 로그인 및 동의 화면을 제공하는 서버가 대표적인 예이다.
일부 자료에서는 설명을 단순화하기 위해 권한 부여 서버와 리소스 서버를 하나로 묶어 설명하기도 하지만 , 아키텍처 관점에서는 이 둘의 책임이 명확히 분리되어 있음을 이해하는 것이 매우 중요하다. 권한 부여 서버는 신원 확인과 동의 처리를 담당하는 반면, 리소스 서버는 제공된 토큰을 기반으로 데이터 접근 제어를 담당한다. 이러한 '관심사의 분리(Separation of Concerns)'는 OAuth 2.0의 핵심적인 설계 특징 중 하나이다.
1.3 결정적 차이: 인증(Authentication)과 인가(Authorization)
OAuth를 정확히 이해하기 위해서는 인증과 인가의 차이를 명확히 구분해야 한다.
인증 (Authentication, AuthN): 사용자가 누구인지 증명하는 과정이다. "당신은 누구입니까?"라는 질문에 답하는 과정으로, 신원을 확인하는 행위이다. Microsoft는 이를 위해 OpenID Connect(OIDC)를 사용한다.
인가 (Authorization, AuthZ): 인증된 사용자가 무엇을 할 수 있는지 결정하는 과정이다. "당신은 무엇을 할 수 있습니까?"라는 질문에 답하는 과정으로, 권한을 부여하는 행위이다. Microsoft는 이를 위해 OAuth 2.0을 사용한다.
핵심 명세인 RFC 6749에 정의된 바와 같이, OAuth 2.0은 엄밀히 말해 인가 프레임워크이지, 인증 프로토콜이 아니다. 이는 클라이언트가 리소스에 접근할 수 있는 권한(액세스 토큰)을 어떻게 획득하는지를 표준화한다. 하지만 OAuth 2.0 자체는 클라이언트가 그 권한을 부여한 사용자의 신원 정보를 어떻게 표준화된 방식으로 알 수 있는지에 대해서는 정의하지 않는다.
이 지점에서 OAuth 2.0의 "인증 공백(Authentication Gap)"이 발생한다. 순수 OAuth 2.0만을 사용하여 "구글로 로그인" 기능을 구현하는 개발자는 액세스 토큰을 받게 된다. 이 토큰은 구글 API(예: 사용자 프로필 정보 API)를 호출하는 데 사용될 수 있다. 그러나 액세스 토큰 자체에는 표준화된 사용자 신원 정보가 포함되어 있지 않다. 클라이언트는 해당 정보를 얻기 위해 별도의 특정 엔드포인트(예: /userinfo 엔드포인트)를 호출해야 하며, 이 과정은 OAuth 2.0에 의해 표준화되지 않았다. 이러한 인증 공백은 OAuth 2.0 위에 일관되고 상호 운용 가능한 방식으로 신원 확인을 처리할 표준 계층의 필요성을 야기했다. 이 필요를 충족시킨 것이 바로 OAuth 2.0 위에 구축된 신원 계층인 **OpenID Connect (OIDC)**이다. 이 인과 관계는 매우 중요하다. 즉, 순수 인가 프레임워크로서의 OAuth 2.0의 한계가 그것의 인증 파트너인 OIDC의 탄생을 직접적으로 이끌었다. 이 내용은 섹션 4에서 심도 있게 다룰 것이다.
섹션 2: 현대적 표준으로의 진화: OAuth 1.0a 대 OAuth 2.0
이 섹션에서는 복잡하고 암호학적으로 무거웠던 OAuth 1.0a에서 간소화되고 TLS에 의존하는 OAuth 2.0으로의 중요한 전환 과정을 역사적 맥락과 함께 기술적으로 분석한다. 이 진화 과정을 이해하는 것은 현대 표준의 설계 철학과 보안 모델을 파악하는 데 핵심적이다.
2.1 구시대의 표준: OAuth 1.0a의 암호학적 접근 방식
OAuth 1.0a는 모든 API 요청이 복잡한 암호화 기법을 사용하여 개별적으로 서명될 것을 요구했다. 각 메시지의 무결성과 진위성을 증명하기 위해 디지털 서명에 기반을 두었으며 , 이로 인해 보안이 메시지 수준에서 처리되어 전송 계층에 독립적(Transport-independent)이었다.
이론적으로 이 접근 방식은 강력하고 안전했다. 서명된 메시지는 그 출처에 귀속되며 변조될 수 없었다. 하지만 개발자 입장에서 이를 올바르게 구현하는 것은 매우 어려웠다. 서명을 생성하고 검증하는 과정의 복잡성은 OAuth 1.0a 채택의 주요 장벽으로 작용했다.
2.2 새로운 표준: OAuth 2.0의 단순성과 확장성에 대한 집중
OAuth 2.0은 1.0과의 하위 호환성이 없는 완전한 재작성(rewrite)의 결과물이다. 이는 개발자들이 더 쉽게 사용할 수 있도록 설계되었으며 , 모든 API 호출에 대해 복잡한 클라이언트 측 암호화 서명을 생성할 필요성을 제거했다. 대신, 통신의 보안을 위해 HTTPS/TLS에 의존하여 당사자 간의 통신 채널 자체를 보호한다. 또한, 토큰의 소유 자체가 접근 권한을 증명하는 베어러 토큰(Bearer Token) 개념을 중심으로 한다.
이러한 변화는 OAuth의 접근성을 극적으로 향상시켰고, 구글, 페이스북, 마이크로소프트와 같은 주요 기업들이 이를 채택하며 광범위하게 확산되는 결과를 낳았다. 또한, OAuth 1.0의 한계였던 웹 브라우저 기반이 아닌 애플리케이션(예: 모바일, 데스크톱)을 포함한 다양한 클라이언트 유형을 지원하기 위해 여러 "Grant 유형(grant types)"을 도입했다.
2.3 보안의 트레이드오프: 패러다임의 전환
1.0에서 2.0으로의 진화는 단순한 '업그레이드'가 아니라 전략적인 트레이드오프의 결과였다. OAuth 1.0a의 암호학적 복잡성은 개발자들에게 높은 진입 장벽이었고, 이는 광범위한 채택을 저해하는 원인이었다. 이에 대응하여 IETF는 주요 산업 플레이어들의 의견을 수렴하여 , 메시지 수준의 보안을 전송 계층 보안(TLS)으로 위임함으로써 OAuth 2.0을 근본적으로 단순화했다.
이러한 단순화는 진입 장벽을 극적으로 낮추어 오늘날 우리가 보는 OAuth 2.0의 보편적인 채택을 이끌었고, API 인가의 사실상 표준(de facto standard)이 되었다. 하지만 이 설계 선택은 보안의 책임을 다른 곳으로 이전시키는 결과를 낳았다. 이제 OAuth 2.0 흐름의 전체 보안은
TLS의 정확하고 견고한 구현에 전적으로 의존하게 되었다. TLS 구성의 사소한 약점(예: 부적절한 인증서 검증, 취약한 암호화 스위트 사용)은 공격자가 중간자 공격(Man-in-the-Middle, MitM)을 통해 베어러 토큰을 탈취할 수 있게 하므로 전체 흐름을 위태롭게 할 수 있다.
결론적으로, 이 진화는 프로토콜 수준의 복잡성을 인프라 수준의 의존성과 맞바꾼 것이다. 이로 인해 OAuth 2.0은 "다루기는 더 쉬워졌지만, 안전하게 구축하기는 훨씬 더 어려워졌다"는 평가를 받게 되었다.
섹션 3: OAuth 2.0 Grant 유형의 세분화된 분석
이 섹션은 "OAuth 종류"에 대한 사용자의 질문에 직접적으로 답하는 보고서의 핵심이다. 각 Grant 유형(흐름)의 작동 방식, 주요 대상, 그리고 보안 프로필을 상세히 분석한다. 이 흐름들의 기초 참조 문서는 공식 명세인 RFC 6749이다.
3.1 황금 표준: Authorization Code Grant
이 흐름은 가장 보편적이고 안전한 방식으로, OAuth 2.0의 기본으로 간주된다. 이는 client_secret을 안전하게 저장할 수 있는 기밀 클라이언트(confidential clients), 예를 들어 서버 사이드 웹 애플리케이션을 위해 설계되었다.
작동 방식
1사용자는 response_type=code 파라미터와 함께 권한 부여 서버로 리디렉션된다.
사용자는 권한 부여 서버에서 인증하고 요청된 권한에 동의한다.
권한 부여 서버는 사용자를 클라이언트의 리디렉션 URI로 다시 보내면서, URL에 수명이 짧고 일회용인 **인가 코드(Authorization Code)**를 포함시킨다.
클라이언트의 백엔드 서버는 이 인가 코드를 받아, 자신의 client_id 및 client_secret과 함께 권한 부여 서버의 토큰 엔드포인트로 안전한 서버 대 서버 직접 호출을 수행한다. 이를 통해 최종적으로 액세스 토큰(및 선택적으로 리프레시 토큰)을 교환받는다.
보안적 근거
이 방식의 핵심적인 보안 특징은 민감한 정보인 액세스 토큰이 사용자의 브라우저(user-agent)에 절대 노출되지 않는다는 점이다. 토큰은 클라이언트의 백엔드 서버로 보안 채널을 통해 직접 전송되므로, 브라우저 기록, 리퍼러 헤더, 또는 악성 스크립트를 통한 유출 위험을 근본적으로 완화한다.
3.2 공개 클라이언트를 위한 현대적 강화: Authorization Code with PKCE
이 섹션은 현대 애플리케이션을 위한 결정적인 진화 과정을 다룬다. 공개 클라이언트(public clients), 즉 단일 페이지 애플리케이션(SPA)이나 네이티브 모바일/데스크톱 앱은 client_secret을 안전하게 저장할 수 없다. 이러한 환경에서는 Authorization Code Grant 단독으로는 취약하다. RFC 7636에 정의된 **PKCE(Proof Key for Code Exchange)**는 공개 클라이언트를 위해 이 흐름을 안전하게 만드는 확장 기술이다.
PKCE가 해결하는 취약점: 인가 코드 탈취 공격
모바일 운영체제에서는 여러 앱이 동일한 커스텀 URL 스킴을 처리하도록 등록할 수 있다. 악성 앱이 합법적인 앱과 동일한 리디렉션 URI를 등록한 경우, 권한 부여 서버가 인가 코드를 담아 리디렉션할 때 운영체제는 사용자에게 어떤 앱으로 열지 묻거나, 악성 앱이 리디렉션을 가로챌 수 있다. 공격자가 이 인가 코드를 탈취하면, 이를 사용하여 액세스 토큰을 발급받아 사용자의 리소스에 접근할 수 있게 된다.
PKCE 작동 방식
(리디렉션 전) 합법적인 클라이언트 앱은 code_verifier라는 임의의 고엔트로피 문자열을 생성한다. 그리고 이 code_verifier를 해시(일반적으로 SHA256)하여 code_challenge를 생성한다.
(인가 요청) 클라이언트는 표준 인가 요청에 code_challenge와 code_challenge_method(예: "S256")를 포함하여 권한 부여 서버로 전송한다. 권한 부여 서버는 이 code_challenge를 저장한다.
(토큰 교환) 클라이언트가 인가 코드를 액세스 토큰으로 교환할 때, 요청에 반드시 원본 비밀값인 code_verifier를 포함해야 한다.
(서버 측 검증) 권한 부여 서버는 전달받은 code_verifier를 동일한 해시 알고리즘으로 변환하여 이전에 저장했던 code_challenge와 비교한다. 두 값이 일치하면, 토큰을 요청하는 클라이언트가 인가 흐름을 시작한 클라이언트와 동일함이 증명되므로 토큰을 발급한다. 일치하지 않으면 요청은 거부된다.
PKCE는 원래 client_secret을 사용할 수 없는 공개 클라이언트를 보호하기 위해 설계되었다. 그러나 보안 커뮤니티는 PKCE가 기밀 클라이언트의 경우에도 인가 코드 주입 공격을 방어하고 CSRF(Cross-Site Request Forgery) 방어 체계를 강화하는 부가적인 이점을 제공한다는 것을 발견했다. 이는 최소한의 비용으로 추가적인 보안 계층을 제공한다. 이러한 이점은 PKCE가 모든 클라이언트에 대해 의무화되어야 한다는 강력한 결론으로 이어졌다. 실제로 'OAuth 2.0 보안 모범 사례(BCP)' 문서와 곧 발표될
OAuth 2.1 명세는 Authorization Code Grant를 사용하는 모든 클라이언트(기밀 클라이언트 포함)에 대해 PKCE 사용을 의무화하고 있다. 특정 사용 사례를 위한 확장에서 핵심 흐름의 필수 구성 요소로 발전한 PKCE의 여정은, 성공적인 보안 강화 기술이 결국 기본 표준에 흡수되어 기본적으로 더 안전한(secure-by-default) 생태계를 구축하는 보안 프로토콜 진화의 핵심적인 경향을 보여준다.
3.3 머신 대 머신 통신의 주역: Client Credentials Grant
이 Grant 유형은 최종 사용자의 개입이 없는 비대화형, 즉 머신 대 머신(Machine-to-Machine, M2M) 통신에 사용된다. 백엔드 서비스, 데몬, CLI, 또는 API와 통신하는 IoT 장치 등이 대표적인 예이다. 이는 때때로 "two-legged OAuth"라고도 불린다.
작동 방식
클라이언트(머신/서비스)는 토큰 엔드포인트로 단일 POST 요청을 직접 보낸다.
요청 본문에는 grant_type=client_credentials, 그리고 자신의 client_id와 client_secret이 포함된다.
권한 부여 서버는 클라이언트의 자격 증명을 검증하고, 유효할 경우 직접 액세스 토큰을 반환한다.
보안적 근거
이 흐름은 사용자 상호작용을 완전히 우회하기 때문에 매우 간단하다. 여기서 인증되는 '신원'은 클라이언트 애플리케이션 그 자체이다. 권한은 관리자에 의해 접근 제어 목록(ACL)이나 사전 구성된 역할을 통해 애플리케이션에 직접 부여된다.
client_secret은 유일한 자격 증명이므로 반드시 안전하게 보관되어야 한다.
3.4 레거시 및 폐기된 흐름: 보안적 부검
OAuth 2.0의 초기에는 편의성을 위해 특정 흐름들이 만들어졌다. 특히 자바스크립트 앱을 위한 Implicit Grant와 레거시 시스템 마이그레이션을 위한 ROPC(Resource Owner Password Credentials) Grant가 그러했다. 그러나 이들의 공식적인 폐기는 단순한 기술 업데이트가 아니라, 전체 생태계의 보안 성숙도를 보여주는 중요한 이정표이다. 이는 커뮤니티가 결함 있는 편의성보다 견고하고 기본적으로 안전한 패턴(예: PKCE를 사용한 Authorization Code Grant)을 우선시하며, 불안정한 레거시 옵션을 적극적으로 제거하는 성숙한 단계에 이르렀음을 의미한다.
Implicit Grant의 취약점: 이 흐름은 사용자 동의 후 액세스 토큰을 URL의 프래그먼트(#) 부분에 담아 직접 반환했다. 프래그먼트는 서버로 전송되지 않지만, 페이지의 자바스크립트에서 접근 가능하며 브라우저 기록, 리퍼러 헤더, 악성 스크립트를 통해 유출될 수 있어 매우 불안전하다. 초기의 존재 이유였던 구형 브라우저의 CORS 지원 부재는 더 이상 유효하지 않다.
ROPC Grant의 안티패턴: 이 Grant는 클라이언트 애플리케이션이 사용자의 실제 아이디와 비밀번호를 직접 수집하여 토큰으로 교환하도록 요구했다. 이는 자격 증명을 공유하지 않고 위임한다는 OAuth의 핵심 원칙을 완전히 위배하는 행위이다. 자격 증명을 클라이언트에 노출시키고, 다중 인증(MFA)을 불가능하게 하며, 공격 표면을 극도로 넓히는 심각한 문제를 안고 있다.
결과적으로, 'OAuth 2.0 보안 모범 사례'와 차기 OAuth 2.1 명세는 이 두 흐름을 공식적으로 폐기하고 사용을 금지했다.
섹션 4: 인가를 넘어서: OpenID Connect(OIDC)를 통한 인증
이 섹션은 OAuth와 OIDC 사이의 흔한 혼동을 명확히 해결한다. OIDC를 OAuth 2.0 인가 프레임워크 위에 구축된 필수적인 신원 계층으로 설명하고, 두 프로토콜이 어떻게 상호 보완적으로 작동하는지 분석한다.
4.1 두 토큰 이야기: ID 토큰 대 액세스 토큰
OIDC는 **ID 토큰(ID Token)**이라는 새로운 결과물을 도입하며, 이는 OAuth 2.0이 제공하는 **액세스 토큰(Access Token)**과는 명확히 구분된다. 이 두 토큰의 분리는 인증과 인가의 관심사 분리를 직접적으로 반영하며, "누구인가?"와 "무엇을 할 수 있는가?"라는 두 가지 근본적인 질문에 대한 답을 제공한다.
ID 토큰 (ID Token): "누구인가?"에 대한 답
목적: 인증(Authentication). 사용자가 권한 부여 서버(이제 OpenID 제공자(Provider) 역할)에 의해 성공적으로 인증되었음을 증명하는 증거이다.
대상: 클라이언트 애플리케이션. 클라이언트가 소비하고 검증하도록 만들어졌다.
형식: 반드시 JSON 웹 토큰(JWT) 형식이어야 한다.
내용: 사용자에 대한 표준화된 클레임(sub, name, email 등)과 인증 이벤트 자체에 대한 정보(iss, aud, exp, iat 등)를 포함한다.
액세스 토큰 (Access Token): "무엇을 할 수 있는가?"에 대한 답
목적: 인가(Authorization). 보호된 리소스(API)에 접근하는 데 사용되는 자격 증명이다.
대상: 리소스 서버(API). 클라이언트가 그 내용을 해석해서는 안 된다.
형식: 어떤 문자열 형식이든 될 수 있다(Opaque). 종종 JWT로 구현되지만, 명세상 필수는 아니다. 클라이언트는 이를 불투명한 문자열로 취급해야 한다.
내용: 리소스 서버가 인가 결정을 내리는 데 필요한 정보, 예를 들어 부여된 권한(scope), 사용자 ID, 클라이언트 ID 등을 포함한다.
이러한 토큰의 이중성은 중요한 보안 경계를 형성한다. 잘못된 토큰을 잘못된 목적으로 사용하는 것은 심각한 취약점을 야기한다. 만약 클라이언트가 API에 접근하기 위해 ID 토큰을 리소스 서버로 보낸다면, 이는 보안 모델을 파괴하는 행위이다. 리소스 서버는 해당 토큰이 자신을 위한 것인지(aud 클레임 불일치) 보장할 수 없으며, 부여된 권한(scope)에 대한 정보도 없다. 반대로, 클라이언트는 액세스 토큰을 파싱하여 사용자 정보를 얻으려 해서는 안 된다. 그 형식은 보장되지 않으며 권한 부여 서버와 리소스 서버 간의 구현 세부 사항일 뿐이기 때문이다.
4.2 OIDC가 진정한 싱글 사인온(SSO)을 구현하는 방법
OIDC는 인증 과정과 신원 정보의 형식(ID 토큰)을 표준화한다. 이를 통해 사용자는 구글이나 Okta와 같은 OpenID 제공자로 한 번 로그인한 후, 그 인증된 세션을 사용하여 여러 독립적인 신뢰 당사자(Relying Parties, 즉 클라이언트)에 자격 증명을 다시 입력하지 않고 로그인할 수 있다. 이 표준화된 흐름과 ID 토큰 형식은 연합 신원(Federated Identity) 및 SSO의 핵심인 상호 운용성을 보장한다.
섹션 5: 전략적 구현 및 권장 사항
이 마지막 섹션은 앞선 모든 분석을 종합하여 아키텍트와 개발자를 위한 실행 가능하고 실용적인 지침을 제공한다.
5.1 의사결정 프레임워크: 올바른 Grant 유형 선택하기
Grant 유형의 선택은 임의적이지 않다. 이는 애플리케이션의 아키텍처와 client_secret 같은 비밀 정보를 안전하게 보관할 수 있는 능력에 따라 결정된다. 다음 표는 이러한 선택을 위한 명확한 가이드라인을 제공한다. 이 결정 매트릭스는 복잡한 정보를 종합하여 한눈에 볼 수 있는 참조 자료로 제공함으로써, 독자가 이론을 실제 아키텍처 결정에 적용할 수 있도록 돕는 강력한 도구 역할을 한다.
표 5.1: OAuth 2.0 Grant 유형 선택 매트릭스
Implicit Grant는 금지된다.5.2 현대적 OAuth 2.0 구현을 위한 보안 모범 사례
다음은 타협할 수 없는 필수 보안 조치들의 통합 체크리스트이다.
항상 HTTPS/TLS 사용: OAuth 2.0의 전체 보안은 여기에 의존한다.
PKCE 의무화: 공개 및 기밀 클라이언트 모두에 대해 Authorization Code Grant와 함께 PKCE를 사용한다.
리디렉션 URI에 대한 정확한 문자열 일치 사용: 공개 리디렉터(Open Redirector) 취약점을 방지한다.
state 파라미터 사용: CSRF 공격을 완화하기 위해 항상 고유하고 예측 불가능한 state 파라미터를 사용한다.
토큰의 정확한 검증: 클라이언트는 ID 토큰을, 리소스 서버는 액세스 토큰을 반드시 검증해야 한다. 여기에는 서명, 발급자(iss), 대상(aud), 만료 시간(exp) 확인이 포함된다.
짧은 수명의 액세스 토큰과 리프레시 토큰 사용: 탈취된 액세스 토큰의 유효 기간을 최소화한다. 사용자를 다시 인증하지 않고 새로운 액세스 토큰을 얻기 위해 (안전하게 저장된) 리프레시 토큰을 사용한다.
5.3 미래: OAuth 2.1 엿보기
OAuth 2.1은 새로운 버전이라기보다는 2.0의 통합 및 강화 버전이다. 이는 모범 사례를 법제화하여 표준을 단순화하는 것을 목표로 한다. OAuth 2.0이 유연한 프레임워크를 지향하며 일부 안전하지 않은 선택지를 포함한 너무 많은 옵션을 제공했던 반면, 지난 10년간 커뮤니티는 어떤 선택이 견고한 보안으로 이어지고 어떤 선택이 취약점으로 이어지는지를 학습했다. OAuth 2.1은 이러한 학습의 정점이다. 새로운 기능을 추가하는 것이 아니라, 나쁜 기능을 제거하고 좋은 기능을 의무화하는 것이다. 이러한 경향은 개발자에게 다양한 안전 수준의 옵션 메뉴를 제공하는 대신, 기본적으로 가장 안전한 구현으로 안내하는 "잘 닦인 길(paved road)"을 지향하는 움직임을 반영한다.
주요 변경 사항은 다음과 같이 요약된다.
PKCE를 사용한 Authorization Code Grant가 유일한 주요 인가 흐름이 된다.
Implicit 및 ROPC Grant가 공식적으로 제거된다.
리디렉션 URI는 정확한 문자열 일치를 사용해야 한다.
쿼리 파라미터를 통한 베어러 토큰 전달이 금지된다.
이러한 변화는 대규모로 안전한 시스템을 구축하는 방법에 대한 성숙한 이해를 바탕으로, 보안을 위한 '위대한 단순화(Great Simplification)'를 추구하는 OAuth 프레임워크의 미래 방향을 명확히 보여준다.
⭐발표자 : 이영청님