OAuth 2.1과 2.0 차이

OAuth 2.1을 알아보기 전에.. 

저는 이전 회사에서 OAuth 2.1 프로토콜을 기준으로 Authorization Code Grant 방식의 인증을 개발한 적이 있습니다. 약 1년전 2023년 12월 쯤 개발을 했었는데, 그 당시에는 OAuth 2.1에 대한 정보가 많이 없었습니다. ChatGPT 역시 OAuth2.1에 대한 정보가 최신화 되지 않아 OAuth2.1을 공부하는 것이 힘들었는데, 이번에 블로그 글을 작성하며 내용을 정리해 보려고 합니다. 

---

OAuth 2.0과 OAuth 2.1의 차이점: 무엇이 달라졌을까?

OAuth는 인터넷 애플리케이션에서 인증과 권한 부여를 안전하게 처리하기 위한 표준 프로토콜입니다. 2012년에 공개된 OAuth 2.0 이후 수년간의 경험을 바탕으로 보안성과 구현 간소화를 위해 OAuth 2.1이 제안되었습니다. 이번 글에서는 OAuth 2.1과 OAuth 2.0의 주요 차이를 정리하고, PKCE에 대해 알아 보도록 하겠습니다.

---

OAuth 2.1이란 무엇인가?

OAuth 2.1은 OAuth 2.0에서 발견된 문제점들을 해결하고 보안 관행을 표준화하는 것을 목표로 합니다. 새로운 기능을 추가하는 대신, 기존 OAuth 2.0의 사양을 통합하고 불필요하거나 위험한 기능을 제거합니다. 이를 통해 OAuth 2.1은 단일 문서로 명확하고 간결하게 구현할 수 있도록 설계되었습니다.

---

OAuth 2.0과 OAuth 2.1의 주요 차이점

1. PKCE의 필수화

• OAuth 2.0: PKCE(Proof Key for Code Exchange)는 공개 클라이언트(예: 모바일 앱)에서 선택적으로 사용되었습니다.
• OAuth 2.1: 모든 Authorization Code Grant 요청에 PKCE가 필수로 적용됩니다. 이는 Authorization Code 탈취 공격을 방지하기 위함입니다.

2. 리다이렉트 URI의 엄격한 일치(strict matching)

• OAuth 2.0: 리다이렉트 URI는 종종 부분 일치(예: 와일드카드 사용)가 허용되었습니다.
• OAuth 2.1: 리다이렉트 URI는 정확히 일치해야 합니다. 이는 악의적인 리다이렉트 공격을 방지하기 위함입니다.

3. Implicit Grant 제거

• OAuth 2.0: Implicit Grant는 클라이언트가 토큰을 직접 받는 방식으로, 보안 위험(예: 토큰 노출)이 존재했습니다.
• OAuth 2.1: Implicit Grant를 완전히 제거하여 Authorization Code Grant를 대신 사용하도록 권장합니다.

4. Resource Owner Password Credentials Grant 제거

• OAuth 2.0: 사용자 자격 증명(ID/비밀번호)을 직접 애플리케이션에 입력받아 OAuth 서버로 전달하는 방식이었습니다.
• OAuth 2.1: 이 방식은 보안 위험이 크므로 제거되었습니다. 대신 PKCE를 사용한 Authorization Code Grant를 권장합니다.

5. Bearer Token의 쿼리 스트링 사용 금지

• OAuth 2.0: Bearer Token은 URI의 쿼리 스트링에 포함될 수 있었습니다.
• OAuth 2.1: Bearer Token은 쿼리 스트링에서 제거되고, 헤더 또는 POST 바디에만 포함될 수 있습니다. 이는 토큰 노출을 방지하기 위함입니다.

6. Refresh Token의 보안 강화

• OAuth 2.1: Refresh Token은 일회용(one-time use) 또는 발급된 클라이언트에만 사용할 수 있도록 제한됩니다. 이는 Refresh Token이 탈취되었을 때 발생할 수 있는 피해를 줄이기 위한 조치입니다.

---

OAuth 2.1의 특징 요약

항목	OAuth 2.0	OAuth 2.1
PKCE 사용	선택 사항	필수 사항
리다이렉트 URI 매칭	부분 일치 허용	정확한 문자열 일치 필요
Implicit Grant	지원	제거
Resource Owner Password Grant	지원	제거
Bearer Token	쿼리 스트링 허용	쿼리 스트링 사용 금지
Refresh Token	일반 토큰 사용	일회용 또는 클라이언트 제약 적용

 

---

PKCE (Proof Key For Code Exchange)

PKCE(Proof Key for Code Exchange)는 OAuth 2.0과 OAuth 2.1에서 Authorization Code Grant 방식을 더 안전하게 사용하기 위해 설계된 보안 메커니즘입니다.

 

PKCE에 대해서는 내용이 길어 질 것 같아 다음 포스팅에 정리 해 두겠습니다.