[OAuth] OAuth 2.1의 등장

Daehwan Kim·2026년 1월 16일

OAuth

목록 보기

2/3

OAuth 2.1 - 왜 등장했고, 무엇이 달라졌는가?

1. OAuth 2.1의 등장 배경

OAuth 2.0은 2012년에 RFC6749로 표준으로 채택된 권한 인가 프레임워크이다. 웹, 모바일, 클라우드 환경이 확장되면서 OAuth 2.0은 사실상 표준 인프라가 되었다.

당연하게도, 10년 넘게 업계에서 표준으로 사용되면서 여러 보안 취약점과 모호한 권장사항이 발견되었다. 또한 다양한 웹 개발 프레임워크의 등장으로 실제 구현 방식이 다양하게 분화되어 표준(RFC, Request For Comments)과 현실의 보안 Best Practice 사이에 괴리가 발생했다.

이러한 문제를 해결하기 위해서 OAuth 2.1 Authorization Framework는 OAuth 2.0 이후 축적된 보안 권고와 구현 경험을 반영해 정리 중인 Internet-Draft이다. 2020년 이후 초안이 지속적으로 갱신되고 있으며, 2026년 현재도 RFC가 아닌 Draft 상태(draft-ietf-oauth-v2-1)이다.

2. OAuth 2.0의 구조적 한계점

2.1 RFC 6749 이후 파생된 문서들

현재 OAuth 2.0은 우리의 git branch처럼 무수히 많은 문서가 분리되어있다. 나는 현대오토에버 부트캠프에서 자체적으로 OAuth 프레임워크를 구축하기 위해, RFC6749부터 OAuth 2.0에 대해 공부했었는데, 어떤 부분은 현재 사용하면 안되는 권한 인가 방식이 존재하는 등으로 OAuth를 제대로 이해하고 구축하는데 너무나도 괴로웠다.

그래서 이번 기회로 얼마나 많은 문서들이 있는지 찾아보았고 RFC6749에서 파생된 문서들은 다음과 같다.

분류	RFC	간단 설명
기본 프레임워크	RFC 6749	OAuth 2.0의 기본 구조를 정의하는 핵심 사양 (Authorization Server, Client, Resource Owner, Flow 정의)
토큰 사용	RFC 6750	HTTP 요청에서 Bearer Access Token을 전달하는 표준 방식 정의
	RFC 7662	Resource Server가 Authorization Server에 토큰 상태를 조회(Introspection)하는 방법
	RFC 7009	Refresh Token 및 Access Token을 명시적으로 폐기(Revoke)하는 표준 API
보안	RFC 6819	OAuth 2.0의 공격 벡터와 위협 모델을 체계적으로 정리한 보안 분석 문서
	RFC 7636	Authorization Code 탈취를 방지하기 위한 PKCE 메커니즘 정의
	RFC 8252	모바일·데스크톱 등 Native App 환경에서의 OAuth 2.0 보안 가이드
	RFC 9700	OAuth 2.0 구현 시 따라야 할 최신 보안 Best Current Practice
	RFC 9449	Access Token을 클라이언트의 공개키에 바인딩하는 DPoP 방식 정의
Grant 확장	RFC 8628	입력 장치가 제한된 기기(TV, 콘솔 등)를 위한 Device Authorization Grant
	RFC 8693	서로 다른 보안 도메인 간 토큰 교환(Token Exchange) 메커니즘
Client 인증	RFC 7521	Assertion 기반 Client 인증 및 Grant 확장을 위한 공통 프레임워크
	RFC 7522	SAML 2.0 Assertion을 OAuth Client 인증/Grant로 사용하는 프로파일
	RFC 7523	JWT Assertion을 OAuth Client 인증/Grant로 사용하는 프로파일
	RFC 8705	Mutual TLS 기반 Client 인증 및 인증서 바인딩 Access Token 정의
요청 보호	RFC 9101	Authorization Request 파라미터를 JWT로 서명하여 위·변조를 방지 (JAR)
	RFC 9126	Authorization Request를 사전에 서버로 전달하는 Pushed Authorization Requests (PAR)
	RFC 9396	Scope를 넘어선 정교한 인가 요구를 표현하는 Rich Authorization Requests (RAR)
토큰 구조	RFC 9068	OAuth 2.0 Access Token을 JWT 형식으로 표준화하는 프로파일

OAuth 2.0 이후에는 토큰 사용, 폐기, PKCE, 네이티브 앱, 브라우저 앱, 보안 Best Current Practice 등 다수의 RFC와 초안 문서가 축적되었다. 따라서 RFC 6749 하나만 읽고 현재 기준의 안전한 구현 방식을 파악하기는 어렵다.

더 큰 문제는 RFC 6749 자체에 오늘날에는 더 이상 권장되지 않는 흐름도 포함되어 있다는 점이다. 최신 구현 기준은 RFC 6749 단독이 아니라 RFC 9700과 관련 최신 초안을 함께 봐야 정확해진다.

2.2 OAuth 2.1 목적 및 차이점

서론이 길었는데, OAuth 공식 홈페이지에서 핵심 OAuth 2.1의 목적과 OAuth 2.0과의 주요 차이점을 정리해주고 있다.

공식 홈페이지 및 문서에서 말하고 있는 주요 목적은 오래되어 사용할 수 없는 Grant와 Flow를 정리하고, 최신의 보안 흐름에 맞도록 몇몇의 기능이 추가되었다는 것이다.

3. OAuth 2.1 Authorization Framework

OAuth 2.1은 아직 RFC로 채택되지 않았지만 2026년 현 시점에서 가장 최신 draft인 draft-ietf-oauth-v2-1-14 버전을 기준으로 OAuth 2.1이 권한 인가를 어떤 관점에서 정의하고 있는지 정리해보고자 한다.

3.1 인가 프레임워크란

전통적 Client-Server 인증 모델에서는 클라이언트가 보호된 리소스에 접근하기 위해서는 리소스 소유자의 자격 증명(ID, Password)을 직접 사용해야했다.

이 모델은 다음과 같은 근본적인 한계를 가진다.

자격 증명은 평문 비밀번호 형태로 존재하기 때문에 본질적으로 취약함.
클라이언트는 사용자의 모든 리소스에 대한 접근 권한을 가지게됨.
특정 애플리케이션에 대한 접근만으로 선택적으로 철회할 수 없음.
접근 차단을 위해서는 비밀번호 변경 외의 다른 수단이 없음.

즉, 클라이언트는 모든 권한을 얻거나, 아무 권한도 얻지 못하는 이분법적인 선택지 밖에 없다.

따라서 OAuth는 이러한 문제를 해결하기 위해 토큰 기반 위임 모델을 도입하는 것이다.

OAuth의 핵심 아이디어는 다음과 같다.

클라이언트는 사용자의 자격 증명을 절대 알지 못한다.
사용자는 클라이언트가 아닌 인가 서버(authorization server)에서 직접 인증한다.
인가 서버는 사용자의 승인 범위(scope)에 한정된 액세스 토큰(Access Token)을 발급한다.
클라이언트는 이 토큰을 사용하여 자원 서버(resource server)의 보호된 자원에 접근한다.

이어서 액세스 토큰은 단순한 인증 수단이 아니라,

접근 가능한 범위(scope)
유효 기간(lifetime)
과 같은 접근 속성의 집합을 담은 위임된 권한 위임 정보이다.

3.2 토큰 기반 위임 모델의 예시

OAuth의 구조를 이해시키기 위해 내가 자주 사용하는 예시가 있는데, 다음과 같다.

사용자는 자신의 일정을 관리하기 위해 차세대 캘린더 애플리케이션(클라이언트)을 사용하고자 한다. 그런데 기존 사용자의 일정 데이터는 구글 캘린더 애플리케이션(자원 서버)에 있어, 위 데이터를 차세대 캘린더 애플리케이션에 연동해야한다.

OAuth 이전의 방식
OAuth가 없던 방식이라면, 클라이언트는 다음과 같은 선택지 밖에 없다.

사용자가 구글 계정의 ID와 비밀번호를 클라이언트(차세대 캘린더 애플리케이션)에 직접 입력한다.
클라이언트는 해당 자격 증명을 저장하거나 중계하여 구글 캘린더 애플리케이션(자원 서버)에 접근한다.

이 방법은 많은 문제를 가지고 있다.

사용자의 구글 자격 증명이 제3자 애플리케이션인 차세대 캘린더 애플리케이션에 노출된다.
클라이언트는 캘린더 애플리케이션의 데이터 뿐만 아니라 사용자의 구글 계정에 있는 모든 자원에 접근 가능하다.
사용자는 특정 애플리케이션에 대한 접근만으로 선택적으로 철회할 수 없다.
접근 차단을 위해 비밀번호 변경 외의 방법이 없다.

즉, 사용자는 **모든 권한을 넘기거나, 아무것도 허용하지 않거나" 두 방법 밖에 없다.

OAuth 이후의 방식

사용자는 차세대 캘린더 애플리케이션에서 "구글 캘린더 연동" 버튼을 누른다.
애플리케이션은 사용자를 구글의 인가 서버로 리디렉션한다.
사용자는 직접 구글 계정으로 인증을 수행한다.
구글은 사용자에게 다음과 같은 동의를 요구한다.
- 캘린더 데이터를 읽기만 하도록 허용할까요?
사용자가 동의하면 구글은 클라이언트에게 액세스 토큰을 발급한다.
클라이언트는 이 액세스 토큰을 사용하여 구글 캘린더의 자원에 접근한다.

이 과정에서 이전의 방식의 문제를 차단할 수 있다.

클라이언트는 사용자의 자격 증명을 알 수 없다.
액세스 토큰에서의 접근 범위가 지정되어 있다.
토큰은 유효기간이 있으므로, 만료되면 더이상 사용할 수 없다.
사용자는 언제든지 구글 계정 설정에서 해당 애플리케이션의 권한만 철회할 수 있다.

자세한 설명은 이전 편에 그림으로 설명해두었습니다. 참고바랍니다.

따라서, OAuth는 인증(Authentication)의 문제와 인가(Authorization)의 문제를 분리할 수 있게 된다.

인증은 리소스를 제공해주는 서버에서 담당하므로 클라이언트는 인증에 대해 알 필요가 없다.

3.3 OAuth 2.1에서의 역할 모델

OAuth 2.1은 OAuth 2.0과 동일한 4가지 역할을 정의하고 있다.

그러나 각 역할에 대한 보안은 더 엄격해졌다.

(1) 자원 소유자(Resource Owner)

보호된 리소스의 소유자
일반적으로 End User
인가 여부를 결정하는 주체

(2) 클라이언트(Client)

보호된 리소스에 접근하려는 애플리케이션
웹 서비스, 모바일 앱, 백엔드 서버 등
OAuth 2.1에서는 기본적으로 신뢰하지 않는 주체임

(3) 인가 서버(Authorization Server)

자원 소유자를 인증함.
클라이언트에게 액세스 토큰을 발급함.
사용자 인증, 승인, 토큰 발급의 중심 역할을 수행함. 리소스 서버는 발급된 토큰을 검증하고 보호 자원 접근을 통제한다.

(4) 자원 서버

액세스 토큰을 검증함.
보호된 리소스를 호스팅하고 요청을 처리함.

3.4 역할 분리와 OAuth 2.1의 보안 관점

OAuth 2.1도 OAuth 2.0과 마찬가지로 각 역할은 논리적으로 분리된 책임을 가진다.

즉, client, authorization server, resource server, resource owner는 각각 다른 보안 책임을 가진 역할로 이해해야한다.

따라서 이는 각 역할이 항상 물리적으로 완전히 분리된 시스템이어야 한다는 뜻은 아니다.

예시로 OAuth 2.0에서도 authorization server와 resource server가 동일한 시스템 또는 동일한 제품군 안에 함께 존재하는 구성이 가능했고, OAuth 2.1도 이에 대한 제약은 없다.

중요한 것을 배치 형태 자체보다 역할과 책임의 경계를 명확히 두는 것이다.

OAuth 2.1과 최신 OAuth 보안 권고에서 더 분명해진 점은 다음과 같다.

클라이언트는 기본적으로 완전히 신뢰할 수 있는 보안 경계로 간주되지 않는다.
사용자 인증과 승인, 토큰 발급의 중심 책임은 authorization server에 있다.
resource server는 전달받은 access token을 검증하고, 해당 토큰의 범위와 대상에 맞는 요청만 허용해야 한다.
클라이언트는 사용자 자격 증명을 직접 수집하거나 처리하지 않는 방향으로 설계해야한다.

즉, OAuth 2.1의 핵심은 보안의 주체와 책임을 역할별로 분리하는 것이다.

클라이언트는 사용자를 대신하여 권한을 요청하는 애플리케이션이고, authorization server는 사용자 인증과 동의, 그리고 토큰 발급의 신뢰 지점이며, resource server는 발급된 토큰을 검증하고 보호 자원 접근을 통제하는 역할을 맡는다.

여기서 주목할만한 점은, 최신 OAuth 보안 기준에서 일반적인 사용자 참여형 클라이언트는 Authorization Code Flow와 PKCE를 기본 흐름으로 사용한다는 점이다.

특히, public client에서는 PKCE가 필수 수준으로 다뤄지며, browser-based client는 Authorization Code를 사용하고 Implicit는 사용하지 않아야 한다. 다만 이것이 사용자가 있는 모든 시나리오에서 오직 하나의 흐름만 존재한다는 의미는 아니다.

특수한 환경에서는 별도의 확장 grant가 사용될 수 있다.

따라서 설계 원칙은 다음처럼 정리할 수 있다.

클라이언트는 사용자 자격 증명을 직접 입력받아 검증하는 주체가 되어서는 안된다.
- 로그인은 authorization server를 통해 수행되어야 하며, 클라이언트는 그 결과로 authorization code 또는 token response를 처리하는 역할을 맡는다.
Authorization server는 사용자 인증, 동의, 토큰 발급의 중심 역할을 수행한다.
Resource Server는 access token을 검증하고, 토큰에 허용된 범위 내에서만 자원 접근을 허용해야한다.
각 역할은 논리적으로 분리되어야 하지만, 물리적 배치까지 표준이 강제하는 것은 아니다.

간단히 정리하면 다음 두 가지를 지키면 OAuth의 핵심 원칙에 가까워질 수 있다.

클라이언트가 사용자 비밀번호를 직접 처리하지 않도록 한다.

로그인과 동의, 토큰 발급은 authorization server를 중심으로 수행하도록 한다.

3.5 OAuth 2.1의 Grant Type

OAuth 2.1은 OAuth 2.0에서 정의되었던 다양한 grant type을 단순히 나열하기보다는, 최신 보안 기준에 맞는 흐름으로 정리했다.

OAuth 2.0 초기에는 웹, 브라우저, 모바일 서버 간 통신 등 다양한 환경을 포괄하기 위해 여러 grant type이 함께 제시되었다. 그러나 시간이 흐름에 따라 일부 grant는 현대의 위협 모델과 잘 맞지 않게 되었고 OAuth 2.1은 이러한 흐름을 최신 보안 권고에 맞게 재정리했다.

Grant Type	목적	OAuth 2.1 관점
Authorization Code Grant + PKCE	사용자 인가 후 토큰 발급	기본 권장 흐름
Implicit Grant	브라우저에서 access token 직접 수령	제외
Resource Owner Password Credentials Grant	사용자가 클라이언트에 ID/비밀번호 직접 전달	제외
Client Credentials Grant	서버-서버 통신	유지
Refresh Token Grant	access token 재발급	유지

이 때 중요한 점은 OAuth 2.1이 모든 상황에서 하나의 grant만 사용하라고 말하는 것은 아니다.

다만, 일반적인 사용자 참여형 웹•모바일 클라이언트에서는 Authorization Code Grant와 PKCE의 조합을 기본 흐름으로 보고, 더 이상 안전하지 않다고 판단된 Implicit Grant와 Resource Owner Password Credentials Grant는 제외하는 방향을 가진다.

따라서 다음과 같이 이해할 수 있다.

사용자의 로그인과 동의가 필요한 경우: Authorization Code Grant + PKCE
사용자 개입 없이 애플리케이션이 자기 자신을 대신해 자원에 접근하는 경우: Client Credential Grant
기존 Access Token이 만료되어 재발급이 필요한 경우: Refresh Token Grant

4. Authorization Code Flow + PKCE

Authorization Code Flow는 사용자가 존재하는 모든 시나리오에서 사용하는 유일한 인가 흐름이다.

4.1 Authorization Code Flow의 목적

Authorization Code Flow의 목적은 아주 간단하다.

사용자가 자격 증명을 클라이언트에 노출하지 않으면서, 사용자가 승인한 범위(scope)의 권한만을 안전하게 위임하는 것

즉, ID, Password를 노출하지 않고 토큰으로 주어진 scope들의 권한만 관리하는 것이다.

4.2 Authorization Code Flow의 특징

해당 Flow를 설명하기 전에 몇 가지 기존 OAuth 2.0에서 추가된 특징(feature)에 대해 알아야한다.

(1) PKCE

PKCE(Proof Key for Code Exchange)는 Authorization Code Flow에서 인가 코드(authorization code)가 탈취되어 액세스 토큰 탈취될 위험 모델에 의해 제안된 보안 확장이다.

OAuth 2.0이 표준이 된 이후, 새로운 위협 모델이 제안되었는데 다음과 같다.
1. 브라우저와 Public Client(SPA, 모바일 앱)은 신뢰할 수 없다.
2. 네트워크, OS, 앱 간 통신은 공격 당할 수 있다.

따라서, OAuth 2.1에서는 Authorization Code Flow에서 PKCE는 필수가 되었다.

PKCE의 구성요소는 다음과 같다.

1. Code Verifier

클라이언트가 생성하는 고난수의 문자열로 Authorization Request 이전 클라이언트 내부에서 생성하며, 외부로 노출되면 안되는 값이다.
Code Verifier를 통해서 Authorization Request를 실제로 시작한 클라이언트를 증명하는 검증 값이다.

2. Code Challenge

Code Verifier로부터 파생된 값으로 Code Verifier를 해시해서 사용한다.
Authorization Request에 포함되어 Authorization Server로 전달된다.

3. Code Challenge Method

Code Challenge가 어떤 방식으로 생성되었는지를 나타내는 값으로, 일반적으로 해시하는 방식인 S256으로 표기한다.

PKCE의 검증 로직은 다음과 같다.
1. Authorization Request 단계
클라이언트는 다음 값을 Authorization Server에 전달하며, 절대 Code Verifier는 전송하지 않는다.

response_type=code
client_id=...
redirect_uri=...
code_challenge=...
code_challenge_method=S256

2. Authorization Code 발급
Authorization Server는 Client로 다음 형태로 Authorization Code를 발급한다.

redirect_uri?code=AUTHORIZATION_CODE

3. Access Token Request 단계
이어 클라이언트는 다음 값을 Authorization Server에 보낸다.

grant_type=authorization_code
code=AUTHORIZATION_CODE
redirect_uri=...
code_verifier=ORIGINAL_CODE_VERIFIER

4. Authorization Server 검증 단계
Authorization Server에서는 1단계에서 보낸 Code Challenge와 해시 방법으로 동일하게 Code Verifier를 생성하고 해당 Code Verifier가 클라이언트가 3단계에서 보낸 Code Verifier와 비교 검증을 수행함.

stored_code_challenge == BASE64URL(SHA256(received_code_verifier))

검증 성공 시, Access Token을 발급하고 그렇지 않으면 요청을 거부한다.

(2) Access Token은 브라우저를 통해 전달되지 않는다.

Access Token은 Client와 Authorization Server의 Token Endpoint와의 HTTP 통신으로만 전달 할 수 있음을 설명한다.

OAuth 2.0의 Implicit Flow에서는 브라우저를 통해서 Access Token을 전달했다.

redirect_uri#access_token=...

그러나 브라우저는 URL 노출, XSS, 히스토리 저장 등의 공격 표면이 다수 존재한다. 토큰이 탈취되면 사용자의 리소스를 직접적으로 접근이 가능하기 때문에 이보다 비교적 위험이 낮은 Authorization Code는 브라우저로 전달하면서 Access Token은 HTTP 통신을 통해서 받을 수 있도록 Implicit Flow는 제거하고 Authorization Code Flow를 권장하는 형태로 변경되었다.

(3) Token 발급은 Authorization Server에서만 수행된다
OAuth 2.1에서는 Token Endpoint의 책임을 명확히 정의하면서 Token 발급은 오로지 Authorization Server에서 가능하다.

(4) Redirect URI는 정확히 일치해야 한다.
Authorization Request시 사용되는 redirect_uri는 Token Request시에도 정확히 동일해야하며, 접미사 또는 부분 일치는 허용하지 않는다.

(5) HTTPS(TLS)는 전제 조건이다.
OAuth 2.1은 HTTP 외 프로토콜을 범위 밖으로 두므로 모든 Endpoint 통신은 TLS(Transport Layer Security)위에서 수행되어야 한다.

TLS는 클라이언트와 서버 사이의 통신을 안전하게 만드는 프로토콜으로 애플리케이션 프로토콜 아래에서 동작하여, HTTPS는 HTTP + TLS를 의미한다.

(6) 사용자 인증은 Authorization Server의 책임이다.
OAuth 2.1은 introduction 부터 authorization(인가) protocol이지 authentication(인증) protocol이 아니라고 명시하고 있다. 이는 OAuth는 사용자가 누구인지 증명하는 방법을 표준으로 정의하지 않는다는 의미로 OAuth는 사용자가 비밀번호 로그인, MFA, 생체 인증 등의 방법을 정의하고 있지 않다는 의미이다.

그러나, OAuth 흐름 안에서 사용자를 실제로 인증해야한다면 해당 행위는 Client가 아니라 Authorization Server에서 일어나야 한다는 것을 의미한다. 클라이언트가 사용자의 자격 증명을 수행한다면, OAuth의 핵심 목표 중 자격 증명 공유 제거와 충돌된다. 이는 인증이 어디서 일어나야하는가에 대한 책임 분리 규칙이다.

이를 통해서, 클라이언트는 사용자 인증 화면을 그리지 않으며, 인증이 Authorization Server의 책임이면 MFA 추가, 인증 정책 변경 등의 인증 방식의 변경을 Client 수정 없이 가능하다.

4.3 Authorization Code Flow의 수행 과정

Authorization Code Flow가 이제 실제로 어떻게 동작하는지 알아볼 차례이다.

여전히 상당히 많은 내용을 알아야하며 이해하기 어렵겠지만, 처음에 말했듯이, OAuth 2.0은 19개의 문서가 있었고, 각 문서에는 이제는 더이상 사용할 수 없는 flow, grant가 함정처럼 존재하고 있다. 그것에 비하면 매우 명료해졌다는 것,,

다시 돌아와서 OAuth 2.1에서 Authorization Code Flow는 Authorization Endpoint -> Token Endpoint 두 개의 엔드포인트를 중심으로 수행되며, 전체 흐름은 다음 5개의 단계로 설명할 수 있다.

(1) Authorization Request

Client가 Authorization Server에서 리소스 소유자인 사용자의 권한을 위임(인가)받고 싶다는 요청을 전달하는 단계이다.

Client는 Authorization Endpoint로 다음 정보와 함께 Authorization Code를 요청한다.

response_type=code
client_id=...
redirect_uri=...
scope=...
state=...
code_challenge=...
code_challenge_method=S256

각 항목은 다음과 같다.

response_type: 응답의 형태로 사실상 Implicit Flow가 삭제되었으므로 code만 허용된다.
client_id: Authorization Server 등록된 클라이언트인지를 검증한다.
redirect_uri: client_id 검증 성공 시, Authorization Code를 전달할 목적지 URI이다.
scope: 클라이언트가 요청하는 접근 권한의 범위로 Access Token에 담길 권한의 제한 조건이다.
state: 클라이언트가 생성한 값으로 CSRF 공격 방지를 위해 Client와 Authorization Server가 서로를 검증하는 값이다.
code_challenge, code_challenge_method: PKCE 값.

(2) 사용자 인증 및 인가

Authorization Server에서 보호된 리소스를 요청하는 사용자를 인증하고 Client가 요청한 권한(scope)에 대해 동의를 받는 단계이다. 클라이언트는 이 과정에서 관여하지 않는다.

(3) Authorization Code 발급

Authorization Server가 Client에게 인가가 승인되었음을 증명하는 Authorization Code를 Client에게 전달한다. 전달 방식은 다음과 같다.

redirect_uri?code=AUTHORIZATION_CODE&state=...

Authorization Code는 짧은 수명, 1회성 및 단독으로는 권한이 없도록 설정하는 것이 필수이다.

(4) Token Request

Authorization Code를 Access Token으로 교환하는 단계로 클라이언트가 Authorization Server의 Token Endpoint로 요청을 수행한다.

주요 파라미터는 다음과 같다.

grant_type=authorization_code
code=AUTHORIZATION_CODE
redirect_uri=...
client_id=...
code_verifier=ORIGINAL_CODE_VERIFIER

(5) Access Token 발급

검증이 완료된 클라이언트에게 Access Token을 발급한다.
응답 예시는 다음과 같다.

{
  "access_token": "...",
  "token_type": "Bearer",
  "expires_in": 3600,
  "refresh_token": "..."
}

OAuth 2.1에서는 OAuth 2.0을 그대로 계승하기 때문에 표준 전달 방식은 JSON, Content-Type: application/json으로 설명하고 있지만, OAuth 2.1에서는 RFC 6710 - Bearer Token Usage도 계승하기 때문에 Token을 어떻게 응답으로 전달하는지는 정의하지 않는다. 따라서 실무에서는 주로 보안을 위해서 HttpOnly, Secure, Cookie로 전달한다.

(6) 보호된 리소스 접근

클라이언트는 발급받은 Access Token을 사용하여 보호된 리소스에 접근한다.

이것으로 사용자가 있는 경우, 보호된 리소스에 접근하기 위한 방법을 OAuth 2.1은 정의하고 있다.

5. Client Credentials Flow

앞서 Authorization Code Flow는 사용자가 존재하는 경우의 권한 인가 방식을 정의하고 있었다. 이어서 그러면 사용자가 없는 경우에서 권한 인가가 필요한 경우에 처리에 대해 OAuth 2.1은 Client Credential Flow로 설명하고 있다.

Client Credentials Flow는 서비스 자체의 권한을 위한 흐름으로 공식문서에서 명시하고 있다.

5.1 Client Credentials Flow의 사용 예시

OAuth 2.1 기준에서는 다음 조건을 모두 만족할 때만 사용한다.

로그인한 사용자가 없다.
권한 위임의 주체가 사용자(사람)이 아니다.
Client 자체의 권한으로 리소스에 접근한다.

위 조건의 사례는 다음과 같다.

마이크로서비스 간 API 호출
백엔드 배치 작업
운영/관리 API

5.2 Client Credentials Flow의 목적

Client Credentials Flow의 목적은 Client 자신을 보호된 리소스의 소유자로 간주하고 서비스 단위의 권한을 명시적으로 표현하기 위함이다.
따라서 발급되는 Access Token은 사용자 동의를 받거나, 대표하지 않으며 오직 Client의 권한만 표현한다.

5.3 Client Credentials Flow의 수행과정

(1) Token Request

Client Credentials Flow는 서버 간 통신에서 수행되므로 Authorization Endpoint는 생략하고 바로 Token Endpoint로 요청을 보낸다. 요청 형식은 다음과 같다.

grant_type=client_credentials
client_id=...
client_secret=...
scope=...

(2) Authorization Server 검증

Authorization Server는 다음을 검증한다.

Client 인증 (client_secret, mTLS, assertion 등)
Client가 요청한 scope에 대한 권한 보유 여부
정책에 따른 토큰 발급 가능 여부

이 단계에서는 사용자 인증은 존재하지 않는다.

(3) Access Token 발급

검증이 성공하면 Authorization Server는 Access Token을 발급한다.

{
  "access_token": "...",
  "token_type": "Bearer",
  "expires_in": 3600
}

(4) 보호된 리소스 접근

클라이언트는 발급받은 Access Token을 사용하여 자원 서버에 자원을 요청한다.

5.4 Authorization Code vs Client Credentials 비교

구분	Authorization Code Flow	Client Credentials Flow
사용자 존재	있음	없음
인증 주체	사용자	Client
Authorization Endpoint	사용	사용 안 함
Token 발급 근거	사용자 위임	Client 권한
PKCE	필수	해당 없음
사용자 리소스 접근	가능	불가

6. Refresh Token Flow

마지막으로 Refesh Token Flow가 있다. 이는 Access Token이 만료되었을 때 사용자(클라이언트)의 재인증 없이 새로운 Access Token을 발급받기 위한 흐름이다. 일반적으로 Authorization Code Flow 위에서 사용된다.

6.1 Refresh Token 수행 과정

Client는 오직 Token Endpoint를 통해 수행된다.

(1) Refresh Token Request

클라이언트는 인가 서버의 토큰 엔드포인로 요청을 보낸다.

grant_type=refresh_token
refresh_token=REFRESH_TOKEN
client_id=...

(2) Authorization Server 검증

Authorization Server는 다음을 검증한다.

Refresh Token의 유효성
만료 여부
철회(revocation) 여부
클라이언트와 Refresh Token의 바인딩 여부

(3) 새로운 Access Token 발급

{
  "access_token": "...",
  "token_type": "Bearer",
  "expires_in": 3600,
  "refresh_token": "NEW_REFRESH_TOKEN"
}

6.2 Refresh Token 보안 특성

리프레시 토큰은 액세스 토큰보다 더 민감하다.

액세스 토큰: 짧은 수명, 탈취 시 피해 제한
리프레시 토큰: 장기 권한 유지 수단
따라서 OAuth 2.1에서는 리프레시 토큰은 액세스 토큰보다 더 엄격하게 보호해야한다.

동시에, OAuth 2.1에서는 리프레시 토큰 회전 정책(refresh token rotation)이 강하게 권장된다. 따라서 리프레시 토큰을 사용할 때마다 기존에 발급했던 리프레시 토큰을 무효화하는 리프레시 토큰 회전이 권장된다.

또한, 공개 클라이언트에서 리프레시 토큰 제약이 존재하는데, SPA, 모바일 앱의 경우에 리프레시 토큰은 발신자 제한 또는 일회용이어야 한다.

이는 RFC 9700의 보안 권고를 OAuth 2.1이 통합한결과이다.

7. 마치며,, 및 개인적인 생각,,

OAuth 2.0 RFC 6749에서는 OAuth의 전반적인 흐름을 정리하는듯하는 느낌이어서 해당 문서 하나만 읽고는 OAuth 2.0을 실제로 구현하는데 어려움이 있었다.

그런데 OAuth 2.1 문서를 보면 매우 상세하게 설명이 되어 있어, Spring Boot, Node.js 등의 어떤 프레임워크를 사용하던지 쉽게 구현할 수 있도록 아주 상세하게 설명이 되어 있다. 예시로 성공 응답이 302이라던지 그런 아주 세부적인 내용까지도 매우 잘 설명되어 있어서 관심이 있는 분이라면 블로그 포스팅도 좋지만, OAuth 2.1 공식 문서를 꼭 읽어보는 것을 추천한다.

그리고 OAuth 2.0이 이제 10년도 지난 프레임워크이기도 해서 개편이 필요하긴 했을 것 같은데, OAuth 2.0부터 2.1까지 공부하면서, 또 이 포스팅을 작성하면서 어떤 생각이 들었냐면,

어느 시니어 개발자가 주니어 개발자에게
“OAuth 표준 기반으로 인가 서버 하나 만들어봐”라는 미션을 주려고 했는데,
막상 자료를 주려 보니 19개의 RFC 문서와 그중에는 이제 쓰면 안 되는 방식까지 섞여 있었다.

그래서 이런 생각을 가진 시니어 개발자들이 "에라이 이거 그냥 정리좀 하자!" 해서 OAuth 2.1을 작성했고, 작성하는 중인 것 같다.

다음으로는 나는 Spring Boot를 개발자이기 때문에 한 번 직접 구현해보는 것에 대한 포스팅을 진행하려고 한다.

참고자료

The OAuth 2.1 Authorization Framework(draft)
OAuth 2.1
Proof Key for Code Exchange by OAuth Public Client

Daehwan Kim

개발 참 즐겁습니다.

이전 포스트

[OAuth] OAuth 2.0의 배경, 개념 및 인가 플로우

다음 포스트

[OAuth] OAuth 2.1의 등장

OAuth

OAuth 2.1 - 왜 등장했고, 무엇이 달라졌는가?

1. OAuth 2.1의 등장 배경

2. OAuth 2.0의 구조적 한계점

2.1 RFC 6749 이후 파생된 문서들

2.2 OAuth 2.1 목적 및 차이점

3. OAuth 2.1 Authorization Framework

3.1 인가 프레임워크란

3.2 토큰 기반 위임 모델의 예시

3.3 OAuth 2.1에서의 역할 모델

(1) 자원 소유자(Resource Owner)

(2) 클라이언트(Client)

(3) 인가 서버(Authorization Server)

(4) 자원 서버

3.4 역할 분리와 OAuth 2.1의 보안 관점

3.5 OAuth 2.1의 Grant Type

4. Authorization Code Flow + PKCE

4.1 Authorization Code Flow의 목적

4.2 Authorization Code Flow의 특징

(1) PKCE

(2) Access Token은 브라우저를 통해 전달되지 않는다.

4.3 Authorization Code Flow의 수행 과정

(1) Authorization Request

(2) 사용자 인증 및 인가

(3) Authorization Code 발급

(4) Token Request

(5) Access Token 발급

(6) 보호된 리소스 접근

5. Client Credentials Flow

5.1 Client Credentials Flow의 사용 예시

5.2 Client Credentials Flow의 목적

5.3 Client Credentials Flow의 수행과정

(1) Token Request

(2) Authorization Server 검증

(3) Access Token 발급

(4) 보호된 리소스 접근

5.4 Authorization Code vs Client Credentials 비교

6. Refresh Token Flow

6.1 Refresh Token 수행 과정

(1) Refresh Token Request

(2) Authorization Server 검증

(3) 새로운 Access Token 발급

6.2 Refresh Token 보안 특성

7. 마치며,, 및 개인적인 생각,,

참고자료

[OAuth] OAuth 2.0의 배경, 개념 및 인가 플로우

[OAuth] Spring Authorization Server로 인가 서버 직접 구축하기

0개의 댓글