8.9 KiB
title, source_type, url, archive_url, status, confidence, related_branches, related_projects, tags, created, last_reviewed
| title | source_type | url | archive_url | status | confidence | related_branches | related_projects | tags | created | last_reviewed | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| RFC 8705 — OAuth 2.0 Mutual-TLS Client Authentication & Certificate-Bound Tokens | official-doc | https://datatracker.ietf.org/doc/html/rfc8705 | raw | high |
|
|
|
2026-05-22 | 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:
- 인용하는 wiki: (미작성)