109 lines
8.9 KiB
Markdown
109 lines
8.9 KiB
Markdown
---
|
|
title: RFC 8705 — OAuth 2.0 Mutual-TLS Client Authentication & Certificate-Bound Tokens
|
|
source_type: official-doc
|
|
url: https://datatracker.ietf.org/doc/html/rfc8705
|
|
archive_url:
|
|
status: raw
|
|
confidence: high
|
|
related_branches: [feature-security-operational-baseline, feature-management-actuator-security-contract]
|
|
related_projects: [ca-skeleton]
|
|
tags: [ca-security, mtls, oauth2, client-authentication, certificate-bound-token, ietf-rfc, official-doc]
|
|
created: 2026-05-22
|
|
last_reviewed: 2026-05-27
|
|
---
|
|
|
|
# RFC 8705 — OAuth 2.0 Mutual-TLS (mTLS) Client Authentication
|
|
|
|
> Layer: `raw/official-docs/` — IETF Standards Track RFC. mTLS client auth + certificate-bound token 사양. ca-skeleton Security Operational Baseline (Group G-B) 의 **대안 4** (mTLS) 비교 근거.
|
|
|
|
## Parent / 활용 branch (필수)
|
|
|
|
| Branch | 이 자료가 정당화하는 결정 |
|
|
|---|---|
|
|
| [[raw/branch-notes/feature-security-operational-baseline]] | JWT bearer baseline 채택 시 mTLS 대안과의 비교 trade-off 근거 |
|
|
| [[raw/branch-notes/feature-management-actuator-security-contract]] | management endpoint 보호 시 mTLS 대안 검토 근거 (sender-constrained token 필요 여부 판단) |
|
|
|
|
## 컨텍스트 / 왜 저장했는지
|
|
|
|
ca-tmpl baseline 은 JWT bearer token 을 채택했지만, 운영 환경 (internal mesh, B2B 결제 API) 에서는 mTLS 가 baseline 일 수 있음. 대안으로서의 비교 근거 + ca-tmpl baseline 이 mTLS 를 채택하지 않은 이유를 명확히 하기 위함.
|
|
|
|
## 출처 / Source
|
|
|
|
- 원본 URL: https://datatracker.ietf.org/doc/html/rfc8705
|
|
- 아카이브 URL: (미수집)
|
|
- 저자 / 조직: IETF — B. Campbell (Ping), J. Bradley (Ping), N. Sakimura (NRI), T. Lodderstedt (yes.com)
|
|
- 발행일: February 2020 (Standards Track)
|
|
- 마지막 확인일: 2026-05-27
|
|
- 관련 표준: FAPI (Financial-grade API) profile 의 권장 client auth 방식
|
|
|
|
## 핵심 인용 / Key quotes (verbatim)
|
|
|
|
> [§Abstract] "This document describes OAuth client authentication and certificate-bound access and refresh tokens using mutual Transport Layer Security (TLS) authentication with X.509 certificates."
|
|
|
|
> [§1 Introduction] "Mutual-TLS certificate-bound access tokens ensure that only the party in possession of the private key corresponding to the certificate can utilize the token to access the associated resources."
|
|
|
|
> [§2.1 PKI Method] "The PKI method of mutual-TLS OAuth client authentication adheres to the way in which X.509 certificates are traditionally used for authentication. It relies on a validated certificate chain and a single subject distinguished name (DN) or a single subject alternative name (SAN)."
|
|
|
|
> [§2.2 Self-Signed Method] "This method of mutual-TLS OAuth client authentication is intended to support client authentication using self-signed certificates... the client's certificate chain is not validated by the server in this case."
|
|
|
|
> [§3 Certificate-Bound Tokens] "When mutual TLS is used by the client on the connection to the token endpoint, the authorization server is able to bind the issued access token to the client certificate."
|
|
|
|
> [§3 Proof-of-Possession] "Such a binding is accomplished by associating the certificate with the token in a way that can be accessed by the protected resource... the client makes protected resource requests... those requests MUST be made over a mutually authenticated TLS connection using the same certificate."
|
|
|
|
## Claims Extracted / 추출된 주장
|
|
|
|
| Claim ID | Claim (이 자료가 직접 말하는 것) | Evidence quote | Strength | Applies to | Does not prove |
|
|
|---|---|---|---|---|---|
|
|
| MTLS-RFC8705-C1 | RFC 8705 는 mutual TLS 와 X.509 certificate 를 사용한 OAuth client authentication 및 **certificate-bound** access/refresh token 을 정의 | [§Abstract] "This document describes OAuth client authentication and certificate-bound access and refresh tokens using mutual Transport Layer Security (TLS) authentication with X.509 certificates." | `official-standard` | OAuth 2.0 client auth 방식 선택 시 | 모든 OAuth deployment 가 mTLS 를 채택해야 한다는 뜻은 아님 — 옵션 중 하나 |
|
|
| MTLS-RFC8705-C2 | certificate-bound access token 은 cert 의 **private key 를 보유한 party 만** 해당 token 으로 resource 접근 가능 (sender-constrained) | [§1] "Mutual-TLS certificate-bound access tokens ensure that only the party in possession of the private key corresponding to the certificate can utilize the token to access the associated resources." | `official-standard` | bearer token 탈취 위협 모델 | private key 자체가 탈취되지 않는다는 뜻은 아님 — key 보관 보안은 별도 |
|
|
| MTLS-RFC8705-C3 | mTLS client auth 의 **2가지 method**: PKI method (validated certificate chain + single DN/SAN) 와 Self-Signed method (chain validation 없음) | [§2.1] "...relies on a validated certificate chain and a single subject distinguished name (DN) or a single subject alternative name (SAN)." + [§2.2] "...the client's certificate chain is not validated by the server in this case." | `official-standard` | RFC 8705 구현 시 method 선택 | PKI method 가 항상 우월하다는 뜻 아님 — Self-Signed 도 spec 인정 (운영 trade-off 별도) |
|
|
| MTLS-RFC8705-C4 | client 가 token endpoint 에 mutual TLS 로 접속하면 authorization server 는 **issued access token 을 client certificate 에 bind** 가능 | [§3] "When mutual TLS is used by the client on the connection to the token endpoint, the authorization server is able to bind the issued access token to the client certificate." | `official-standard` | token endpoint 운영 시 cert binding 결정 | 모든 AS 가 자동으로 binding 한다는 뜻은 아님 — 구현 옵션 |
|
|
| MTLS-RFC8705-C5 | certificate-bound token 사용 시 protected resource request 는 **동일한 certificate** 로 mutual TLS connection 위에서 수행 **MUST** | [§3] "...the client makes protected resource requests... those requests MUST be made over a mutually authenticated TLS connection using the same certificate." | `official-standard` | resource access 단계 client 동작 | client 가 cert 를 rotate 시 어떻게 binding 이 갱신되는지 (별도 절차) |
|
|
|
|
## Usage Boundaries / 적용 경계
|
|
|
|
- **이 자료가 직접 증명하는 것**:
|
|
- `MTLS-RFC8705-C1` ~ `C5`: mTLS client auth + certificate-bound token 의 spec 정의, sender-constrained 속성, 2가지 method, binding 의무.
|
|
- **이 자료가 증명하지 않는 것**:
|
|
- mTLS 가 JWT bearer 보다 "항상 더 안전하다" 는 명제 — 운영 환경 (PKI 운영 능력, 클라이언트 종류) 에 따라 다름.
|
|
- 브라우저 SPA / mobile client 에 mTLS 가 부적합하다는 명제 — RFC 는 적용 범위 제한을 둠 (브라우저 UX 한계는 별도 관찰).
|
|
- Istio / Linkerd 같은 service mesh 의 auto-mTLS 와 RFC 8705 의 일치성 — service mesh 는 보통 inter-service TLS 만 다루며 OAuth token binding 까지는 별도.
|
|
- PKI 운영 비용 (CA, CRL, OCSP) 의 정량 평가.
|
|
- **내 프로젝트에 적용하려면 추가 확인이 필요한 것**:
|
|
- ca-tmpl 의 actuator/management endpoint 가 internal-only 인 경우 mTLS 가 baseline 후보로 적합한지 (network boundary 정의 필요).
|
|
- Spring Security 의 RFC 8705 지원 범위 (벤더 doc 별도 확인).
|
|
- cert rotation 운영 절차 — JWT key rotation 과 별개의 procedure 필요.
|
|
|
|
## 메모 / Notes (내 프로젝트 해석)
|
|
|
|
> 본 섹션은 자료 직접 인용 아님. ca-tmpl baseline 결정 해석.
|
|
|
|
- **vs JWT bearer (ca-tmpl baseline)**:
|
|
- bearer = "token 가진 자가 권한 보유" → token 탈취 시 그대로 사용 가능.
|
|
- mTLS certificate-bound = token + private key 둘 다 있어야 사용 가능 → token sender constraint.
|
|
- **언제 mTLS 가 baseline 이 되는가**:
|
|
- B2B / inter-service mesh (Istio 처럼 sidecar 가 자동 mTLS).
|
|
- FAPI 같은 금융 프로파일.
|
|
- zero-trust internal traffic.
|
|
- **ca-tmpl 이 채택하지 않은 이유 (추정)**:
|
|
- public API / mobile client 대응이 어려움 (cert 발급/회수 cost).
|
|
- skeleton 단계에서 PKI 운영 (CA, CRL, OCSP) 부담을 부과하지 않음.
|
|
- **actuator/management endpoint 보호용** 으로는 별도 검토 가치 있음 (G-B 두 번째 branch).
|
|
- **장점**:
|
|
- sender-constrained → bearer 탈취 시나리오 차단.
|
|
- 인증 + 채널 암호화가 한 layer.
|
|
- **단점**:
|
|
- 인증서 발급/배포/회수 운영 비용.
|
|
- mobile / 브라우저 SPA 적용 난이도 큼 (브라우저 cert UX 빈약).
|
|
- cert rotation = JWT key rotation 과 별개 운영 절차 필요.
|
|
|
|
## Related / 관련
|
|
|
|
- 같은 주제 다른 official-doc:
|
|
- [[raw/official-docs/security-jwt-rfc-7519-validation]] (JWT bearer baseline 비교 기준)
|
|
- [[raw/official-docs/security-oauth2-pkce-rfc-8252]] (또 다른 OAuth proof-of-possession 메커니즘)
|
|
- 인용하는 branch:
|
|
- [[raw/branch-notes/feature-security-operational-baseline]]
|
|
- [[raw/branch-notes/feature-management-actuator-security-contract]]
|
|
- 인용하는 wiki: (미작성)
|