OAuth 2.0 프로토콜의 역할과 흐름에 대한 심층 분석

오늘날의 디지털 생태계는 수많은 애플리케이션과 서비스가 서로 데이터를 주고받는 초연결 사회입니다. 사용자는 날씨 앱이 자신의 위치 정보에 접근하기를 원하고, 사진 편집 앱이 클라우드 스토리지의 사진을 불러오기를 기대하며, 소셜 미디어 계정으로 새로운 서비스에 간편하게 로그인하기를 원합니다. 이러한 상호작용의 중심에는 '어떻게 제3자 애플리케이션에 내 비밀번호를 노출하지 않고 안전하게 데이터 접근 권한을 부여할 수 있는가?'라는 근본적인 질문이 존재합니다. 이 질문에 대한 가장 보편적이고 강력한 해답이 바로 OAuth 2.0입니다.

OAuth 2.0은 단순히 '소셜 로그인'을 위한 기술이 아닙니다. 이는 인증(Authentication)과 구별되는 권한 부여(Authorization)를 위한 개방형 표준 프로토콜입니다. 즉, 사용자가 특정 서비스에 저장된 자신의 데이터(리소스)에 대해, 다른 애플리케이션이 특정 범위 내에서 접근할 수 있도록 권한을 위임하는 과정을 체계화한 프레임워크입니다. 이 과정을 통해 사용자는 자신의 자격증명(예: 아이디와 비밀번호)을 제3자 애플리케이션에 직접 제공하는 위험을 감수할 필요가 없어지며, 데이터 소유권을 유지한 채 필요한 기능만 선택적으로 허용할 수 있게 됩니다.

이 글에서는 OAuth 2.0이 등장하게 된 배경부터 시작하여 프로토콜을 구성하는 핵심 역할과 개념, 다양한 시나리오에 맞춰 설계된 권한 부여 흐름(Grant Types), 그리고 OpenID Connect(OIDC)와의 관계 및 보안 고려사항까지 깊이 있게 탐구하고자 합니다. 이를 통해 개발자와 설계자가 OAuth 2.0을 단순한 구현의 대상을 넘어, 안전하고 확장 가능한 디지털 서비스를 구축하는 핵심 원리로 이해하는 데 도움을 드리고자 합니다.

1. 문제의 시작: 비밀번호 공유의 위험성(The Password Anti-Pattern)

OAuth가 등장하기 이전, 제3자 애플리케이션이 사용자 데이터에 접근하는 가장 원시적인 방법은 사용자에게 직접 아이디와 비밀번호를 요구하는 것이었습니다. 예를 들어, 트위터에 올린 글을 자동으로 분석해주는 서비스가 있다고 상상해 봅시다. 이 서비스는 사용자의 트윗 데이터에 접근해야 하므로, 사용자에게 트위터 아이디와 비밀번호를 입력하라고 요구했을 것입니다. 이를 '비밀번호 안티패턴(Password Anti-Pattern)'이라고 부릅니다.

이 방식은 여러 가지 심각한 보안 문제를 야기합니다.

• 과도한 권한 부여: 애플리케이션은 단순히 트윗을 읽는 기능만 필요함에도 불구하고, 비밀번호를 확보함으로써 사용자의 계정으로 할 수 있는 모든 권한(트윗 작성, DM 전송, 계정 설정 변경 등)을 갖게 됩니다. 이는 '최소 권한의 원칙(Principle of Least Privilege)'에 정면으로 위배됩니다.
• 보안 신뢰 문제: 사용자는 제3자 애플리케이션이 자신의 비밀번호를 안전하게 저장하고 관리할 것이라고 맹목적으로 신뢰해야 합니다. 만약 해당 애플리케이션이 해킹당하면, 사용자의 비밀번호는 유출되어 다른 서비스에서도 연쇄적인 피해를 일으킬 수 있습니다.
• 권한 철회의 어려움: 사용자가 더 이상 해당 애플리케이션의 데이터 접근을 원치 않을 경우, 유일한 방법은 자신의 비밀번호를 변경하는 것입니다. 이는 해당 비밀번호를 사용하는 모든 애플리케이션의 접근을 동시에 차단하는 불편함을 초래합니다.
• 취약한 사용자 경험: 사용자들은 보안에 민감하기 때문에 자신의 핵심 자격증명을 낯선 서비스에 제공하는 것을 꺼립니다. 이는 서비스 전환율을 낮추는 주요 원인이 됩니다.

OAuth는 이러한 문제들을 해결하기 위해 '위임(Delegation)'이라는 개념을 도입했습니다. 마치 호텔에서 물리적인 마스터 키를 주는 대신, 특정 객실만 정해진 시간 동안 출입할 수 있는 카드 키를 발급하는 것과 같습니다. 사용자는 자신의 마스터 키(비밀번호)를 주지 않고, 제한된 권한을 가진 카드 키(Access Token)를 애플리케이션에 발급해주는 것입니다. 이것이 바로 OAuth 2.0의 핵심 철학입니다.

2. OAuth 2.0의 핵심 구성 요소: 4가지 역할과 토큰

OAuth 2.0 프로토콜은 표준화된 용어로 정의된 네 가지 주요 역할(Role)의 상호작용을 기반으로 동작합니다. 이 역할들을 명확히 이해하는 것이 전체 흐름을 파악하는 첫걸음입니다. 구체적인 예시로 '프린트리(Printly)'라는 사진 인화 서비스 앱이 사용자의 '포토클라우드(PhotoCloud)'에 저장된 사진에 접근하려는 시나리오를 통해 각 역할을 살펴보겠습니다.

2.1. 네 가지 핵심 역할(Roles)

1. 리소스 소유자 (Resource Owner)
   • 정의: 보호된 리소스(데이터)에 대한 최종 소유권을 가진 주체. 대부분의 경우 최종 사용자(End-User)를 의미합니다.
   • 예시: '포토클라우드'에 자신의 사진 앨범을 저장해 둔 사용자. 사용자는 자신의 사진에 대한 접근 권한을 '프린트리' 앱에 부여할지 결정할 권한이 있습니다.
2. 클라이언트 (Client)
   • 정의: 리소스 소유자를 대신하여 보호된 리소스에 접근을 요청하는 애플리케이션. 클라이언트는 웹 애플리케이션, 모바일 앱, 데스크톱 앱, 서버사이드 서비스 등 다양한 형태일 수 있습니다.
   • 예시: 사용자의 '포토클라우드' 사진을 인화하기 위해 사진 데이터 접근을 요청하는 '프린트리' 앱.
3. 권한 서버 (Authorization Server)
   • 정의: 리소스 소유자로부터 성공적으로 인증(Authentication) 및 동의(Consent)를 얻은 후, 클라이언트에게 접근 토큰(Access Token)을 발급하는 서버. 핵심적인 보안 관문 역할을 합니다.
   • 예시: '프린트리' 앱이 정말로 사용자의 허락을 받았는지 확인하고, 확인이 되면 제한된 시간과 범위 내에서 사진에 접근할 수 있는 '열쇠(접근 토큰)'를 발급해주는 '포토클라우드'의 인증 시스템.
4. 리소스 서버 (Resource Server)
   • 정의: 보호된 리소스를 호스팅하는 서버. 클라이언트로부터 접근 토큰을 제시받으면, 해당 토큰의 유효성을 검증하고 요청된 리소스를 제공합니다.
   • 예시: 사용자의 사진 앨범 데이터가 실제로 저장되어 있는 '포토클라우드'의 API 서버. 이 서버는 '프린트리' 앱이 제시한 접근 토큰이 유효한 경우에만 사진 데이터를 반환합니다.

실제 환경에서는 권한 서버와 리소스 서버가 동일한 시스템 내에 구현될 수도 있고, 물리적으로나 논리적으로 분리될 수도 있습니다. 중요한 것은 각 역할이 명확하게 정의된 책임을 수행한다는 점입니다.

2.2. 핵심 자격 증명: 토큰(Tokens)과 범위(Scopes)

OAuth 2.0의 권한 위임은 '토큰'이라는 특수한 문자열 형태의 자격 증명을 통해 이루어집니다. 가장 중요한 두 가지 토큰은 접근 토큰과 갱신 토큰입니다.

접근 토큰 (Access Token)

클라이언트가 리소스 서버에 접근하기 위해 사용하는 핵심적인 자격 증명입니다. 마치 특정 기간 동안만 유효한 출입 카드와 같습니다.

• 목적: 리소스 서버에 대한 API 요청 시 자신을 인증하고 허가된 권한을 증명하는 데 사용됩니다. 일반적으로 HTTP 요청의 `Authorization` 헤더에 `Bearer` 스킴과 함께 포함되어 전송됩니다. (Authorization: Bearer [ACCESS_TOKEN])
• 짧은 수명: 접근 토큰은 보안을 위해 일반적으로 수명이 짧습니다(수 분에서 수 시간). 만약 토큰이 탈취되더라도 공격자가 시스템에 접근할 수 있는 시간이 제한됩니다.
• 형식: OAuth 2.0 명세 자체는 접근 토큰의 형식을 규정하지 않습니다. 단순한 불투명 문자열(Opaque String)일 수도 있고, 토큰 자체가 정보를 담고 있는 JWT(JSON Web Token) 형식일 수도 있습니다. JWT 형식의 토큰은 토큰 내에 만료 시간, 허용된 범위(scope), 발급자 등의 정보를 포함할 수 있어 리소스 서버가 권한 서버에 별도로 문의하지 않고도 토큰을 검증할 수 있는 장점(Self-contained)이 있습니다.

갱신 토큰 (Refresh Token)

접근 토큰이 만료되었을 때, 사용자의 재인증 과정 없이 새로운 접근 토큰을 발급받기 위해 사용하는 토큰입니다.

• 목적: 사용자 경험을 향상시킵니다. 접근 토큰의 수명이 다할 때마다 사용자에게 다시 로그인하라고 요구한다면 매우 불편할 것입니다. 갱신 토큰을 사용하면 클라이언트는 백그라운드에서 권한 서버와 통신하여 새로운 접근 토큰을 조용히 발급받을 수 있습니다.
• 긴 수명과 높은 보안 요구: 갱신 토큰은 접근 토큰보다 훨씬 긴 수명(수 일에서 수 개월, 또는 영구)을 가집니다. 따라서 이 토큰이 유출되면 공격자가 지속적으로 새로운 접근 토큰을 발급받을 수 있으므로, 매우 안전하게 저장 및 관리되어야 합니다. 일반적으로 클라이언트의 서버 측과 같이 보안이 확보된 환경에 저장하며, 브라우저와 같은 공개된 환경에는 저장하지 않습니다.
• 선택적 발급: 모든 권한 부여 흐름에서 갱신 토큰이 발급되는 것은 아닙니다. 보안 수준이 높은 흐름(예: Authorization Code Grant)에서 주로 사용됩니다.

범위 (Scope)

Scope는 클라이언트가 리소스 소유자에게 요청하는 접근 권한의 범위를 명시적으로 정의하는 메커니즘입니다. 이는 '최소 권한의 원칙'을 구현하는 핵심적인 도구입니다.

• 목적: 클라이언트에게 필요한 최소한의 권한만을 부여하여, 과도한 권한 획득으로 인한 보안 위험을 줄입니다.
• 예시: '프린트리' 앱은 사용자의 사진을 읽어야 하지만, 사진을 삭제하거나 사용자 프로필을 수정할 필요는 없습니다. 따라서 '포토클라우드'에 권한을 요청할 때 scope=read_photos와 같이 명시할 수 있습니다. 사용자는 동의 화면에서 '프린트리' 앱이 '사진 읽기' 권한만을 요청하고 있음을 명확히 인지하고 동의할 수 있습니다. 리소스 서버는 나중에 '프린트리' 앱이 제시한 접근 토큰에 read_photos scope가 포함되어 있는지 확인하고, 이 범위를 벗어나는 요청(예: 사진 삭제 API 호출)은 거부합니다.

3. 시나리오별 권한 부여 흐름 (Authorization Grant Types)

OAuth 2.0의 가장 큰 특징 중 하나는 클라이언트의 유형과 사용 시나리오에 따라 최적화된 여러 가지 '권한 부여 승인 흐름(Grant Type)'을 제공한다는 점입니다. 모든 애플리케이션이 동일한 방식으로 토큰을 발급받지 않습니다. 예를 들어, 서버 백엔드를 가진 웹 애플리케이션과 순수 브라우저 기반의 SPA(Single-Page Application), 그리고 사용자가 직접 개입하지 않는 서버 간 통신은 각기 다른 보안 요구사항을 가집니다. 이제 가장 중요하고 널리 사용되는 Grant Type들을 살펴보겠습니다.

3.1. 권한 부여 코드 승인 방식 (Authorization Code Grant)

가장 표준적이고 안전한 방식으로, 서버 측 백엔드를 가진 전통적인 웹 애플리케이션에 적합합니다. 이 흐름은 사용자의 브라우저(Front-channel)와 클라이언트 서버-권한 서버 간의 직접 통신(Back-channel)을 모두 활용하여 보안을 강화한 것이 특징입니다.

동작 흐름:

1. 사용자 권한 요청: 사용자가 클라이언트 앱('프린트리')에서 '포토클라우드로 로그인' 버튼을 클릭합니다. 클라이언트는 사용자를 권한 서버의 인증 페이지로 리디렉션시킵니다. 이때 요청 URL에는 클라이언트를 식별하는 client_id, 요청하는 권한 범위를 나타내는 scope, 인증 성공 후 돌아올 주소인 redirect_uri, CSRF 공격 방지를 위한 state 값, 그리고 이 흐름을 사용하겠다는 response_type=code가 포함됩니다.
2. 사용자 인증 및 동의: 사용자는 권한 서버('포토클라우드') 페이지에서 자신의 아이디와 비밀번호로 로그인하고, '프린트리' 앱이 요청한 권한(예: '사진 읽기')에 대해 동의(Consent)합니다.
3. 권한 코드 발급: 권한 서버는 사용자의 동의를 확인한 후, 일회성의 짧은 수명을 가진 권한 코드(Authorization Code)를 생성합니다. 그리고 사용자를 1단계에서 지정된 redirect_uri로 다시 리디렉션시키면서, 이 권한 코드를 쿼리 파라미터로 함께 전달합니다. (예: `https://printly.com/callback?code=AUTH_CODE&state=...`)
4. 접근 토큰 교환 요청 (Back-channel): 사용자의 브라우저는 이 리디렉션을 따라 클라이언트의 콜백 URL로 이동합니다. 클라이언트의 서버 백엔드는 URL에서 권한 코드를 추출합니다. 이제 클라이언트 서버는 이 권한 코드와 자신의 client_id, 그리고 비밀 키인 client_secret을 사용하여 권한 서버의 토큰 엔드포인트에 접근 토큰(Access Token)을 직접 요청합니다. 이 통신은 브라우저를 거치지 않는 서버 간의 안전한 통신(Back-channel)입니다.
5. 접근 토큰 및 갱신 토큰 발급: 권한 서버는 전달받은 권한 코드, client_id, client_secret을 모두 검증합니다. 모든 것이 유효하면, 마침내 접근 토큰과 (필요하다면) 갱신 토큰(Refresh Token)을 클라이언트 서버에 발급합니다.
6. 리소스 접근: 클라이언트는 발급받은 접근 토큰을 사용하여 리소스 서버('포토클라우드' API)에 사용자의 사진 데이터를 요청하고, 성공적으로 응답을 받습니다.

이 방식의 핵심 보안 요소는 민감한 정보인 접근 토큰이 브라우저와 같은 불안전한 환경에 노출되지 않고, 안전한 서버 간 통신(Back-channel)을 통해서만 전달된다는 점입니다.

3.2. PKCE 확장 권한 부여 코드 승인 방식 (Authorization Code Grant with PKCE)

PKCE(Proof Key for Code Exchange)는 모바일 앱, 네이티브 데스크톱 앱, 그리고 최신 SPA와 같이 client_secret을 안전하게 저장할 수 없는 'Public Client'를 위해 설계된 보안 확장 기능입니다. 현재는 모든 종류의 클라이언트에게 권장되는 가장 안전한 방식입니다.

문제점: 기존의 Authorization Code Grant에서, 만약 공격자가 모바일 기기에서 앱 간 통신을 가로채 권한 코드를 탈취한다면, 그리고 공격자가 자신의 악성 클라이언트로 이 코드를 사용하여 토큰을 요청한다면, 권한 서버는 이 요청이 정당한 클라이언트로부터 온 것인지 확인할 방법이 없습니다(Public Client는 `client_secret`이 없으므로).

PKCE의 해결책: PKCE는 권한 코드를 요청하는 클라이언트와 해당 코드로 토큰을 요청하는 클라이언트가 동일한 주체임을 동적으로 증명하는 메커니즘을 추가합니다.

동작 흐름 (Authorization Code Grant에 추가되는 부분):

1. (추가) Code Verifier & Challenge 생성: 클라이언트는 권한 요청을 시작하기 전에, 먼저 code_verifier라는 임의의 비밀 문자열을 생성합니다. 그리고 이 code_verifier를 SHA256 해시 함수 등으로 변환하여 code_challenge를 생성합니다.
2. (수정) 사용자 권한 요청: 1단계의 권한 요청 URL에 code_challenge와 사용된 해시 알고리즘을 나타내는 code_challenge_method를 추가하여 권한 서버로 보냅니다.
3. (서버 저장) 권한 서버는 전달받은 code_challenge를 발급할 권한 코드와 함께 저장해 둡니다.
4. ... (기존 흐름의 2, 3단계는 동일) ...
5. (수정) 접근 토큰 교환 요청: 클라이언트가 권한 코드로 접근 토큰을 요청할 때, 이번에는 원본 비밀 문자열인 code_verifier를 요청에 포함하여 보냅니다.
6. (서버 검증) 권한 서버는 토큰 요청으로 받은 code_verifier를 저장해 두었던 code_challenge_method(예: SHA256)를 사용해 변환합니다. 이 결과값이 저장해 두었던 code_challenge와 일치하는지 비교합니다. 일치해야만 두 요청이 동일한 클라이언트로부터 시작되었음이 증명되며, 접근 토큰을 발급합니다.

만약 중간에 공격자가 권한 코드를 탈취하더라도, 원본 code_verifier를 모르기 때문에 토큰 교환 요청을 성공시킬 수 없습니다. 이로써 Public Client 환경에서도 권한 코드 탈취 공격을 효과적으로 방어할 수 있습니다.

3.3. 클라이언트 자격증명 승인 방식 (Client Credentials Grant)

이 흐름은 사용자의 개입 없이, 클라이언트 애플리케이션 자체가 리소스의 소유자인 경우(예: 서버 간 통신, M2M)에 사용됩니다. 사용자의 데이터가 아닌, 클라이언트 자신이 관리하는 데이터나 서비스에 접근할 때 사용됩니다.

동작 흐름:

1. 토큰 요청: 클라이언트가 자신의 client_id와 client_secret을 사용하여 권한 서버의 토큰 엔드포인트에 직접 접근 토큰을 요청합니다.
2. 토큰 발급: 권한 서버는 클라이언트의 자격증명을 확인하고, 유효하다면 즉시 접근 토큰을 발급합니다.

사용자 인증 및 동의 과정이 완전히 생략되므로 매우 단순한 흐름입니다. 예를 들어, 결제 서비스 API를 호출하여 상품 정보를 조회하거나, 내부 데이터 분석 시스템이 다른 마이크로서비스의 데이터를 가져오는 등의 시나리오에 적합합니다.

3.4. 더 이상 권장되지 않는 레거시 흐름

• 암시적 승인 방식 (Implicit Grant): 과거에는 서버 백엔드가 없는 SPA를 위해 사용되었습니다. 권한 서버가 접근 토큰을 redirect_uri의 프래그먼트(#)를 통해 브라우저에 직접 전달하는 방식입니다. 하지만 접근 토큰이 브라우저 히스토리나 로그에 노출될 위험이 크고, 갱신 토큰을 사용할 수 없는 등 보안상 취약점이 많아 현재는 PKCE를 사용한 Authorization Code Grant로 대체되었습니다.
• 리소스 소유자 암호 자격증명 승인 방식 (Resource Owner Password Credentials Grant): 클라이언트가 사용자로부터 직접 아이디와 비밀번호를 받아서 권한 서버에 전달하여 토큰을 발급받는 방식입니다. 이는 OAuth의 핵심 철학인 비밀번호 공유 방지에 위배되며, 서비스 제공자가 직접 만든 앱과 같이 클라이언트를 완전히 신뢰할 수 있는 매우 제한적인 경우에만 사용되었습니다. 이 역시 보안 위험이 커 현재는 사용이 강력히 비권장됩니다.

4. 인증과 권한 부여: OpenID Connect(OIDC)와의 관계

OAuth 2.0을 이야기할 때 흔히 발생하는 혼동 중 하나는 이를 '인증(Authentication)' 프로토콜로 오해하는 것입니다. OAuth 2.0은 근본적으로 '권한 부여(Authorization)'를 위한 프레임워크입니다. 즉, '이 클라이언트가 특정 리소스에 접근할 수 있는가?'에 대한 답을 제공할 뿐, '이 사용자가 누구인가?'에 대한 표준화된 방법을 제공하지는 않습니다.

예를 들어, 클라이언트가 구글 OAuth 2.0을 통해 접근 토큰을 얻었다고 해서, 그 토큰만으로는 사용자의 이메일 주소나 이름과 같은 신원 정보를 표준적인 방법으로 알아낼 수 없습니다. 물론 구글이 제공하는 특정 API를 호출하면 사용자 정보를 얻을 수는 있지만, 이는 구글에 종속적인 방식일 뿐입니다.

이러한 인증의 공백을 메우기 위해 등장한 것이 바로 OpenID Connect(OIDC)입니다. OIDC는 OAuth 2.0 프로토콜 위에 구축된 얇은 신원(Identity) 계층입니다. OIDC는 OAuth 2.0의 권한 부여 흐름을 그대로 사용하면서, 인증과 관련된 몇 가지 확장을 추가합니다.

OIDC의 핵심 추가 요소

• ID 토큰 (ID Token): OIDC의 핵심입니다. ID 토큰은 JWT(JSON Web Token) 형식이며, 인증된 사용자에 대한 기본 정보를 담고 있습니다. (예: sub - 사용자의 고유 식별자, iss - 토큰 발급자, aud - 토큰 대상자(클라이언트 ID), exp - 만료 시간 등). 클라이언트는 이 ID 토큰의 서명을 검증함으로써 사용자의 신원을 안전하게 확인할 수 있습니다.
• `openid` Scope: 클라이언트가 OIDC 인증을 요청하려면, OAuth 2.0 요청의 scope 파라미터에 반드시 openid 값을 포함해야 합니다. 이 scope가 포함되면 권한 서버는 접근 토큰과 함께 ID 토큰을 발급해 줍니다. 추가로 profile, email 등의 scope를 요청하여 ID 토큰에 더 많은 사용자 정보를 담도록 요청할 수 있습니다.
• UserInfo 엔드포인트: ID 토큰에 담기에는 너무 많은 추가적인 사용자 정보(예: 주소, 전화번호 등)를 얻기 위해 표준화된 API 엔드포인트입니다. 클라이언트는 발급받은 접근 토큰을 사용하여 이 엔드포인트에 사용자 정보를 요청할 수 있습니다.

결론적으로, '로그인' 기능을 구현하고자 한다면 여러분이 실제로 필요한 것은 OIDC입니다. 반면, 순수하게 다른 서비스의 API에 접근하는 기능(예: 파일 업로드, 캘린더 일정 추가)만을 구현한다면 순수 OAuth 2.0만으로 충분할 수 있습니다. 현대의 '소셜 로그인'은 대부분 OAuth 2.0을 기반으로 한 OIDC를 사용하고 있다고 이해하면 정확합니다.

5. OAuth 2.0의 진화와 미래: OAuth 2.1을 향하여

OAuth 2.0은 2012년에 발표된 이후 10년 넘게 업계 표준으로 자리 잡았지만, 그동안 다양한 보안 취약점이 발견되고 새로운 모범 사례들이 정립되었습니다. 이러한 변화를 반영하여 IETF(국제 인터넷 표준화 기구) OAuth 워킹그룹은 차세대 버전인 OAuth 2.1의 표준화를 진행하고 있습니다.

OAuth 2.1은 완전히 새로운 프로토콜이 아니라, 기존 OAuth 2.0의 모범 사례를 집대성하고 보안상 취약한 부분을 제거하여 명세를 단순화하고 강화하는 것을 목표로 합니다.

OAuth 2.1의 주요 변경 사항

• PKCE를 기본으로 채택: 모든 클라이언트 유형의 Authorization Code Grant 흐름에서 PKCE 사용을 의무화합니다.
• 리디렉션 URI의 정확한 일치 요구: 와일드카드나 서브도메인을 허용하지 않고, 사전에 등록된 리디렉션 URI와 정확히 일치할 것을 요구하여 보안을 강화합니다.
• 암시적 승인 방식(Implicit Grant) 폐기: 보안에 취약한 Implicit Grant(`response_type=token`)를 명세에서 완전히 제거합니다.
• 리소스 소유자 암호 자격증명 승인 방식 폐기: Password Grant 역시 명세에서 제거됩니다.
• Bearer Token 헤더 형식 유지: Bearer 토큰을 URI 쿼리 파라미터로 전달하는 것을 금지하고, 오직 `Authorization` 헤더를 통해서만 전달하도록 강제합니다.

이러한 변화는 OAuth 2.0을 더욱 안전하고 일관성 있게 만들어 줄 것입니다. 비록 OAuth 2.1이 아직 최종 확정(RFC) 단계는 아니지만, 이미 많은 서비스 제공자들이 이러한 모범 사례들을 구현에 반영하고 있습니다. 따라서 새로 OAuth 2.0을 도입하는 개발자라면 처음부터 OAuth 2.1의 가이드라인을 따르는 것이 현명한 선택입니다.

OAuth 2.0과 그 위에 구축된 OIDC는 현대 디지털 서비스의 상호운용성과 보안을 책임지는 핵심 기반 기술입니다. API 경제, 마이크로서비스 아키텍처, 그리고 제로 트러스트 보안 모델이 확산됨에 따라, 리소스 접근을 안전하게 위임하고 관리하는 이 프로토콜의 중요성은 앞으로 더욱 커질 것입니다. 개발자로서 OAuth 2.0의 각 흐름과 보안적 함의를 깊이 이해하는 것은, 단순히 기능을 구현하는 것을 넘어 사용자의 데이터를 책임감 있게 다루고 신뢰를 구축하는 첫걸음이 될 것입니다.