💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

들어가며

API 하나가 뚫리면 계좌 이체가 일어나는 세계가 있습니다. 오픈뱅킹, 마이데이터, 오픈파이낸스가 그 세계입니다. 이런 환경에서 "일반적인 OAuth 2.0 베스트 프랙티스"만으로는 부족하다는 문제의식에서 출발한 것이 OpenID Foundation의 FAPI(Financial-grade API) 워킹그룹이고, 그 결과물이 [FAPI 2.0 Security Profile](https://openid.net/specs/fapi-2_0-security-profile.html)입니다.

2026년 현재 FAPI는 더 이상 금융권만의 이야기가 아닙니다. FAPI 2.0 Security Profile과 Attacker Model이 Final 사양으로 확정되었고, 브라질 오픈파이낸스, 영국 오픈뱅킹, 호주 CDR, 사우디아라비아 오픈뱅킹 등 국가 단위 생태계가 FAPI 기반으로 운영되고 있습니다. 헬스케어, 정부 디지털 서비스처럼 높은 보증 수준이 필요한 도메인도 FAPI를 차용하는 추세입니다. 그리고 [Keycloak 26.6](https://www.keycloak.org/docs/latest/release_notes/index.html)이 FAPI 2.0 Security Profile과 Message Signing의 Final 버전을 공식 지원하면서, 오픈소스 IdP로도 금융급 프로파일을 구축할 수 있는 환경이 완성되었습니다.

이 글에서는 FAPI 1.0에서 2.0으로의 진화 배경, 핵심 요구사항, DPoP와 mTLS의 선택 기준, Keycloak 설정, 그리고 일반 서비스가 FAPI에서 가져갈 수 있는 교훈까지 정리합니다.

FAPI가 해결하려는 문제 — 공격자 모델

FAPI 2.0의 출발점은 [Attacker Model](https://openid.net/specs/fapi-2_0-attacker-model.html)이라는 별도 문서입니다. 일반 OAuth가 암묵적으로 가정하는 것보다 훨씬 강한 공격자를 상정합니다.

- 네트워크 상의 공격자: 인가 요청/응답을 읽고 변조할 수 있음

- 악성 리소스 서버: 클라이언트가 실수로 토큰을 보낼 수 있는 가짜 RS

- 악성 인가 서버 혼합(mix-up): 클라이언트가 여러 AS를 쓸 때 응답을 뒤섞는 공격

- 유출된 인가 응답/요청: 브라우저 히스토리, 로그, 리퍼러를 통한 노출

이 공격자 모델 하에서도 토큰 오용과 세션 탈취가 불가능해야 한다는 것이 FAPI 2.0의 목표이며, 실제로 형식 검증(formal analysis)을 통해 보안 속성이 증명되었습니다. "베스트 프랙티스 모음"이 아니라 "증명된 보안 프로파일"이라는 점이 FAPI 2.0의 가장 큰 차별점입니다.

FAPI 1.0에서 2.0으로 — 단순화의 역사

FAPI 1.0은 Baseline과 Advanced 두 프로파일로 나뉘어 있었고, Advanced는 하이브리드 플로우, JARM, 요청 객체 서명 등 구현 난도가 높은 메커니즘을 요구했습니다. 구현체마다 해석이 갈렸고, 적합성 테스트를 통과하는 데 수개월이 걸리는 일이 흔했습니다.

FAPI 2.0은 "보안 수준은 유지하되 복잡도를 낮춘다"는 방향으로 재설계되었습니다.

| 항목 | FAPI 1.0 Advanced | FAPI 2.0 Security Profile |

|------|-------------------|---------------------------|

| 프로파일 구조 | Baseline + Advanced 이원화 | 단일 Security Profile + 선택적 Message Signing |

| 인가 요청 보호 | 서명된 요청 객체(JAR) 또는 하이브리드 플로우 | PAR로 일원화 |

| 인가 응답 보호 | JARM 또는 하이브리드 플로우의 ID 토큰 | authorization code + PKCE로 충분 |

| 응답 타입 | code id_token 등 혼재 | code 단일 |

| 토큰 바인딩 | mTLS 중심 | DPoP 또는 mTLS 선택 |

| 형식 검증 | 부분적 | 전체 프로파일 형식 검증 완료 |

핵심 통찰은 이렇습니다. 인가 요청을 프런트채널(브라우저 리다이렉트)로 보내는 대신 백채널로 미리 등록(PAR)하면, 요청 변조 방어를 위한 복잡한 서명 장치가 필요 없어집니다. 마찬가지로 PKCE와 발급자 식별(iss 응답 파라미터)이 코드 주입과 mix-up을 막아주므로, 하이브리드 플로우의 복잡성도 제거할 수 있었습니다.

FAPI 2.0 Security Profile 핵심 요구사항

FAPI 2.0이 인가 서버와 클라이언트에 요구하는 사항을 압축하면 다음과 같습니다.

1. PAR(Pushed Authorization Requests, RFC 9126) 필수 — 모든 인가 요청은 백채널로 사전 등록

2. PKCE(S256) 필수 — confidential 클라이언트라도 예외 없음

3. response_type은 code만 사용

4. sender-constrained access token 필수 — DPoP 또는 mTLS 인증서 바인딩

5. 클라이언트 인증은 private_key_jwt 또는 mTLS(tls_client_auth) — client_secret 계열 금지

6. iss 응답 파라미터(RFC 9207)로 mix-up 공격 방어

7. refresh token도 sender-constrained

8. 인가 코드 1회성, 정확한 redirect_uri 매칭 등 RFC 9700 수준의 기본기

플로우 전체를 그림으로 보면 다음과 같습니다.

+----------+ +---------------+

| Client | | Auth Server |

+----+-----+ +-------+-------+

| (1) POST /par |

| private_key_jwt + PKCE + 요청 파라미터 일체 |

| ---------------------------------------------> |

| (2) request_uri (한 번 쓰고 버리는 참조) |

| <--------------------------------------------- |

| |

| (3) 브라우저 리다이렉트: client_id+request_uri |

| ---------------------------------------------> |

| (4) 사용자 인증/동의 후 code + iss 반환 |

| <--------------------------------------------- |

| |

| (5) POST /token |

| code + code_verifier + private_key_jwt |

| (+ DPoP proof 또는 mTLS) |

| ---------------------------------------------> |

| (6) sender-constrained access token |

| <--------------------------------------------- |

| |

| (7) API 호출: token + DPoP proof/mTLS 인증서 |

v v

PAR(RFC 9126) — 인가 요청을 백채널로

전통적인 인가 요청은 쿼리 스트링에 모든 파라미터를 실어 브라우저로 보냅니다. 이 방식은 파라미터가 변조될 수 있고, 브라우저 히스토리와 서버 로그에 남으며, URL 길이 제한에도 걸립니다. [PAR](https://datatracker.ietf.org/doc/html/rfc9126)은 인가 요청 본문을 클라이언트가 인증된 백채널로 미리 등록하고, 브라우저에는 참조값(request_uri)만 보내는 방식입니다.

POST /realms/fin/protocol/openid-connect/ext/par/request HTTP/1.1

Host: idp.bank.example

Content-Type: application/x-www-form-urlencoded

client_id=tpp-client

&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer

&client_assertion=eyJhbGciOiJQUzI1NiIs...

&response_type=code

&redirect_uri=https%3A%2F%2Ftpp.example%2Fcallback

&scope=accounts%20payments

&code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM

&code_challenge_method=S256

&state=af0ifjsldkj

응답은 다음과 같습니다.

{

"request_uri": "urn:ietf:params:oauth:request_uri:6esc_11ACC5bwc014ltc14eY22c",

"expires_in": 90

}

이후 브라우저 리다이렉트는 극단적으로 단순해집니다.

GET /authorize?client_id=tpp-client

&request_uri=urn:ietf:params:oauth:request_uri:6esc_11ACC5bwc014ltc14eY22c

인가 서버는 등록 시점에 이미 클라이언트를 인증하고 파라미터를 고정했으므로, 브라우저 구간에서의 변조가 원천 차단됩니다. request_uri는 1회용이며 수명이 짧습니다(보통 90초 내외).

RAR(RFC 9396) — 거래 수준의 세밀한 인가

scope 문자열로는 "계좌 A에서 B로 15만 원 이체" 같은 거래 수준 인가를 표현하기 어렵습니다. [RAR(Rich Authorization Requests)](https://datatracker.ietf.org/doc/html/rfc9396)는 authorization_details라는 JSON 구조로 이를 해결합니다.

{

"authorization_details": [

{

"type": "payment_initiation",

"instructedAmount": {

"currency": "KRW",

"amount": "150000"

"creditorAccount": {

"iban": "KR123456789012345678"

"remittanceInformation": "2026-06 임대료"

}

]

}

이 구조는 PAR 요청에 포함되어 사용자 동의 화면에 거래 내용 그대로 표시되고, 발급된 액세스 토큰에도 authorization_details로 박제됩니다. 리소스 서버는 토큰 속의 거래 정보와 실제 API 요청이 일치하는지 검증합니다. "동의한 것만, 동의한 만큼만"이 암호학적으로 강제되는 것입니다. FAPI 2.0에서 RAR은 필수는 아니지만, 결제 시나리오에서는 사실상 표준 조합입니다.

Sender-Constrained Token — DPoP vs mTLS

FAPI 2.0의 가장 중요한 요구사항은 bearer 토큰 금지, 즉 sender-constrained token 의무화입니다. 토큰이 유출되어도 정당한 보유자만 사용할 수 있어야 합니다. 선택지는 두 가지입니다.

mTLS 인증서 바인딩(RFC 8705)

[RFC 8705](https://datatracker.ietf.org/doc/html/rfc8705)는 TLS 클라이언트 인증서의 지문(thumbprint)을 토큰에 바인딩합니다. 토큰의 cnf 클레임에 인증서 해시가 들어갑니다.

{

"sub": "user-1234",

"aud": "https://api.bank.example",

"cnf": {

"x5t#S256": "bwcK0esc3ACC3DB2Y5_lESsXE8o9ltc05O89jdN-dg2"

}

리소스 서버는 TLS 핸드셰이크에서 제시된 클라이언트 인증서의 해시와 토큰의 cnf 값을 비교합니다. TLS 계층에서 자동으로 강제되므로 애플리케이션 코드 변경이 적지만, 인증서 발급/순환 인프라(PKI)와 TLS 종료 지점 관리가 까다롭습니다. 특히 로드밸런서가 TLS를 종료하는 구조에서는 인증서 정보를 백엔드로 전달하는 추가 설정이 필요합니다.

DPoP(RFC 9449)

[DPoP](https://datatracker.ietf.org/doc/html/rfc9449)는 애플리케이션 계층에서 증명 JWT를 매 요청에 첨부하는 방식입니다. 클라이언트가 공개키/개인키 쌍을 만들고, 토큰 요청과 API 호출마다 해당 키로 서명한 proof를 DPoP 헤더로 보냅니다. 토큰에는 공개키 지문이 cnf의 jkt로 바인딩됩니다.

{

"sub": "user-1234",

"aud": "https://api.bank.example",

"cnf": {

"jkt": "0ZcOCORZNYy-DWpqq30jZyJGHTN0d2HglBV3uiguA4I"

}

선택 기준 비교

| 기준 | mTLS(RFC 8705) | DPoP(RFC 9449) |

|------|----------------|----------------|

| 동작 계층 | TLS(전송) | HTTP(애플리케이션) |

| 인프라 요구 | PKI, mTLS 가능한 LB/게이트웨이 | 없음(키는 클라이언트가 생성) |

| 공개 클라이언트(SPA/모바일) | 사실상 불가 | 적합 |

| 클라이언트 인증 겸용 | 가능(tls_client_auth) | 불가(토큰 바인딩 전용) |

| 프록시/CDN 통과 | TLS 종료 지점마다 설정 필요 | 투명하게 통과 |

| 구현 복잡도 | 인프라 쪽에 집중 | 클라이언트 코드 쪽에 집중 |

| 전형적 채택처 | 은행 간 B2B, 폐쇄망 | 핀테크 앱, 퍼블릭 클라이언트 |

거칠게 요약하면, 서버 간 통신과 기존 PKI가 있는 환경은 mTLS, 모바일 앱과 SPA가 낀 환경은 DPoP가 자연스럽습니다. 둘을 혼용하는 생태계도 많습니다(클라이언트 인증은 private_key_jwt, 토큰 바인딩은 DPoP 등).

FAPI 2.0 Message Signing — 부인 방지가 필요할 때

Security Profile이 "전송 중 보호"를 담당한다면, [FAPI 2.0 Message Signing](https://openid.net/specs/fapi-2_0-message-signing.html)은 부인 방지(non-repudiation)를 추가합니다. 분쟁 발생 시 "이 요청/응답이 정확히 이 내용으로 오갔다"를 제3자에게 증명해야 하는 규제 환경을 위한 것입니다.

- 인가 요청 서명: JAR(RFC 9101)로 요청 객체 서명

- 인가 응답 서명: JARM으로 응답을 서명된 JWT로 수신

- 리소스 요청/응답 서명: HTTP Message Signatures(RFC 9421) 활용

Message Signing은 필요한 메시지 유형에만 선택적으로 적용할 수 있습니다. 브라질 오픈파이낸스처럼 규제가 요구하는 시장에서 주로 채택됩니다.

Keycloak 26.6에서 FAPI 2.0 구성하기

Keycloak은 client policies 메커니즘으로 FAPI 요구사항을 강제합니다. 26.6은 FAPI 2.0 Security Profile과 Message Signing의 Final 사양에 대응하는 내장 프로파일을 제공합니다. 내장 글로벌 프로파일 이름은 fapi-2-security-profile, fapi-2-message-signing입니다.

client policy는 "조건(어떤 클라이언트에)" + "프로파일(어떤 요구사항을)"의 조합입니다. 예를 들어 특정 클라이언트 롤을 가진 클라이언트 전체에 FAPI 2.0을 강제하는 정책을 JSON으로 정의하면 다음과 같습니다.

{

"policies": [

{

"name": "fapi2-for-openbanking-clients",

"description": "Enforce FAPI 2.0 Security Profile on all open banking clients",

"enabled": true,

"conditions": [

{

"condition": "client-roles",

"configuration": {

"roles": ["openbanking-tpp"]

}

"profiles": ["fapi-2-security-profile"]

}

]

}

Admin CLI로 적용합니다.

현재 정책 확인

kcadm.sh get client-policies/policies -r fin

정책 업데이트 (위 JSON을 policies.json으로 저장했다고 가정)

kcadm.sh update client-policies/policies -r fin -f policies.json

이 정책이 걸린 클라이언트가 FAPI 요구사항을 어기면 — 예컨대 PAR 없이 인가 요청을 하거나, client_secret으로 인증하거나, PKCE를 빠뜨리면 — Keycloak이 요청 자체를 거부합니다. 클라이언트 등록 시점에도 executor가 작동해 비준수 설정(예: 허용되지 않은 서명 알고리즘)을 막습니다.

함께 점검할 realm 레벨 설정입니다.

PAR 요청 수명 (기본 60초, FAPI 권장 범위 내 유지)

kcadm.sh update realms/fin -s 'attributes."parRequestUriLifespan"="90"'

DPoP 활성화 확인 (26.x에서 지원)

kcadm.sh get realms/fin --fields attributes

클라이언트에 mTLS 토큰 바인딩 강제

kcadm.sh update clients/CLIENT-UUID -r fin \

-s 'attributes."tls.client.certificate.bound.access.tokens"="true"'

26.6에서는 EdDSA 서명 지원도 추가되어, 향후 알고리즘 정책 수립 시 선택지가 넓어졌습니다. 다만 FAPI 2.0이 허용하는 알고리즘은 PS256, ES256 계열이 중심이므로 생태계 요구사항을 먼저 확인해야 합니다.

적합성 테스트 — Conformance Suite

FAPI의 큰 장점은 "준수했는지"를 기계적으로 검증할 수 있다는 점입니다. OpenID Foundation이 제공하는 [conformance suite](https://www.certification.openid.net/)는 인가 서버와 클라이언트를 상대로 수백 개의 시나리오(정상 플로우, 변조된 요청, 잘못된 서명, 만료된 토큰 등)를 자동 실행합니다.

운영 관점의 팁입니다.

1. 인증(certification) 전에 로컬에서 스위트를 돌려보십시오. 스위트는 오픈소스이며 Docker로 구동할 수 있습니다.

2. 테스트 대상 환경은 프로덕션과 동일한 TLS/프록시 구성이어야 합니다. LB가 헤더를 바꾸면서 생기는 실패가 많습니다.

3. 실패 메시지는 스펙 조항 번호와 함께 나오므로, 스펙 문서를 옆에 두고 읽는 것이 가장 빠릅니다.

4. Keycloak은 FAPI 적합성 인증을 받은 구현이지만, 여러분의 배포 구성(리버스 프록시, 커스텀 SPI)이 적합성을 깨뜨릴 수 있습니다. 배포 단위로 재검증하는 것이 안전합니다.

한국 금융권 관점 — 마이데이터 API와 FAPI

한국의 마이데이터(본인신용정보관리업) 생태계는 금융보안원 주도의 표준 API 규격을 사용합니다. 현행 규격은 FAPI를 그대로 채택한 것은 아니지만, 구조적으로 유사한 요소가 많습니다 — 기관 간 상호 인증, 전송 구간 암호화, 접근토큰 기반 인가, 정보 제공 동의의 세분화 등입니다.

FAPI 2.0 관점에서 마이데이터류 시스템을 설계/개선할 때 가져갈 수 있는 포인트는 다음과 같습니다.

- 동의 내용의 토큰 바인딩: RAR의 authorization_details처럼 동의 범위를 토큰에 구조적으로 박는 설계는 "동의 외 조회" 사고를 기술적으로 차단합니다.

- bearer 토큰 탈피: 기관 간 API에서 mTLS 바인딩, 사용자 단말이 끼는 구간에서 DPoP를 검토할 수 있습니다.

- 국제 정합성: 해외 오픈뱅킹과의 상호운용이나 글로벌 핀테크 진출을 고려하면, 국내 규격 위에 FAPI 2.0 호환 계층을 두는 전략이 유효합니다.

- 적합성 테스트 문화: 규격 문서 + 수동 점검 중심에서, conformance suite 스타일의 자동화된 상호운용성 검증으로 옮겨가는 것이 생태계 전체의 비용을 줄입니다.

일반 서비스가 FAPI에서 배울 점

여러분의 서비스가 금융이 아니어도, FAPI 2.0은 "OAuth를 제대로 쓰면 어디까지 갈 수 있는가"의 레퍼런스입니다. 비용 대비 효과가 좋은 순서로 추리면 다음과 같습니다.

1. PKCE 전면 적용 — OAuth 2.1에서 어차피 의무입니다. 지금 켜십시오.

2. 정확한 redirect_uri 매칭, code 1회성 — 설정 변경만으로 가능한 수준입니다.

3. PAR 도입 — 클라이언트 변경이 필요하지만, 인가 요청 변조와 로그 유출 문제를 구조적으로 제거합니다.

4. private_key_jwt로 클라이언트 인증 전환 — 공유 시크릿의 유출/순환 문제에서 해방됩니다.

5. 고위험 API에 한해 DPoP — 전체 적용이 부담이면 결제/개인정보 API부터.

반대로, Message Signing이나 mTLS 전면 도입은 규제 요구가 없다면 과투자일 수 있습니다. FAPI 2.0 자체가 "필요한 만큼만"의 철학으로 단순화된 프로파일이라는 점을 기억하십시오.

글로벌 생태계 현황과 단계별 도입 로드맵

FAPI 2.0을 채택했거나 전환 중인 주요 생태계를 비교하면 다음과 같습니다.

| 생태계 | 기반 프로파일 | 토큰 바인딩 | 특징 |

|--------|--------------|------------|------|

신규 도입 조직을 위한 단계별 로드맵을 제안합니다.

Phase 0 현황 파악

- 클라이언트 인벤토리, 인증 방식, PKCE 적용률 조사

Phase 1 기반 다지기 (호환성 영향 없음)

- PKCE S256 전 클라이언트 적용

- redirect_uri 완전 일치, code 1회성 확인

- RFC 9207 iss 파라미터 검증 추가

Phase 2 클라이언트 인증 전환

- client_secret -> private_key_jwt 마이그레이션

- JWKS 엔드포인트 운영, 키 순환 절차 수립

Phase 3 요청 보호

- PAR 도입, require_pushed_authorization_requests 강제

Phase 4 토큰 바인딩

- 파일럿 클라이언트에 DPoP 또는 mTLS 적용

- 리소스 서버 cnf 검증 배포

Phase 5 정책화와 검증

- Keycloak client policies로 전체 강제

- conformance suite 회귀 테스트 파이프라인 구축

각 Phase는 독립적으로 가치가 있으므로, 전체 완료 전이라도 보안 수준이 단계적으로 올라갑니다.

리소스 서버에서의 cnf 검증 구현

FAPI의 마지막 마일은 리소스 서버입니다. Spring 기반 리소스 서버에서 mTLS 바인딩 토큰의 cnf를 검증하는 예시입니다.

public class CertificateBoundTokenValidator

implements OAuth2TokenValidator<Jwt> {

@Override

public OAuth2TokenValidatorResult validate(Jwt jwt) {

Map<String, Object> cnf = jwt.getClaim("cnf");

if (cnf == null || cnf.get("x5t#S256") == null) {

return OAuth2TokenValidatorResult.failure(

new OAuth2Error("invalid_token",

"cnf claim missing - sender-constrained token required",

null));

}

String boundThumbprint = (String) cnf.get("x5t#S256");

// 프록시가 전달한 클라이언트 인증서에서 지문 계산

String presentedThumbprint = CertificateThumbprintHolder.current();

if (!boundThumbprint.equals(presentedThumbprint)) {

return OAuth2TokenValidatorResult.failure(

new OAuth2Error("invalid_token",

"certificate thumbprint mismatch", null));

}

return OAuth2TokenValidatorResult.success();

}

핵심은 "cnf가 없으면 거부"입니다. sender-constrained를 의무화한 환경에서 cnf 없는 토큰을 통과시키면 다운그레이드 공격 경로가 열립니다.

트러블슈팅과 안티패턴

FAPI 프로파일을 적용할 때 자주 만나는 문제들입니다.

증상 원인과 대처

----------------------------------------------------------------

invalid_request: PAR required 클라이언트가 request_uri 없이

/authorize 직행. 클라이언트 SDK의

PAR 지원 여부 확인.

invalid_client (PAR 단계) private_key_jwt의 aud/exp 오류,

JWKS 미등록 또는 키 순환 후 구 키 사용.

invalid_dpop_proof proof의 htm/htu 불일치(프록시가

URL 재작성), iat 시계 오차, jti 재사용.

cnf 불일치로 401 LB가 TLS 종료 후 인증서 미전달.

프록시에서 인증서 헤더 전달 설정 필요.

PKCE 검증 실패 code_verifier 저장 위치 문제(다중

인스턴스 환경의 세션 비고정).

안티패턴도 짚어둡니다.

- FAPI 정책을 일부 클라이언트에만 적용하고 동일 API를 비FAPI 클라이언트에도 열어두는 것 — 보안 수준은 가장 약한 경로로 수렴합니다.

- request_uri 수명을 길게 늘리는 것 — PAR의 1회성/단명성이 보안 근거의 일부입니다.

- conformance를 한 번 통과한 뒤 재검증 없이 구성 변경 — 프록시/알고리즘/SPI 변경 시마다 회귀 테스트가 필요합니다.

마치며

FAPI 2.0은 "강한 공격자 모델 아래서 형식 검증된, 그러나 구현 가능한" 보안 프로파일이라는 점에서 OAuth 생태계의 중요한 이정표입니다. 요약합니다.

- FAPI 1.0의 복잡성(하이브리드 플로우, JARM 필수)은 PAR + PKCE + code 플로우로 단순화되었습니다.

- sender-constrained token이 핵심입니다. 인프라 성숙도에 따라 mTLS 또는 DPoP를 선택하십시오.

- Keycloak 26.6의 내장 client policies로 FAPI 2.0 Final을 선언적으로 강제할 수 있습니다.

- 적합성은 conformance suite로 기계 검증하고, 배포 구성 변경 시마다 회귀시키십시오.

- 금융이 아니어도 PKCE, PAR, private_key_jwt는 보편적 이득입니다.

높은 보증 수준의 인가가 필요한 모든 곳에서, FAPI 2.0은 이미 검증된 출발점을 제공합니다. 바퀴를 다시 발명하기 전에 이 프로파일을 먼저 읽어보시기를 권합니다.

참고 자료

- [FAPI 2.0 Security Profile](https://openid.net/specs/fapi-2_0-security-profile.html)

- [FAPI 2.0 Attacker Model](https://openid.net/specs/fapi-2_0-attacker-model.html)

- [FAPI 2.0 Message Signing](https://openid.net/specs/fapi-2_0-message-signing.html)

- [RFC 9126 — OAuth 2.0 Pushed Authorization Requests](https://datatracker.ietf.org/doc/html/rfc9126)

- [RFC 9396 — OAuth 2.0 Rich Authorization Requests](https://datatracker.ietf.org/doc/html/rfc9396)

- [RFC 9449 — OAuth 2.0 Demonstrating Proof of Possession (DPoP)](https://datatracker.ietf.org/doc/html/rfc9449)

- [RFC 8705 — OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens](https://datatracker.ietf.org/doc/html/rfc8705)

- [RFC 9207 — OAuth 2.0 Authorization Server Issuer Identification](https://datatracker.ietf.org/doc/html/rfc9207)

- [RFC 9700 — Best Current Practice for OAuth 2.0 Security](https://datatracker.ietf.org/doc/html/rfc9700)

- [RFC 7636 — Proof Key for Code Exchange (PKCE)](https://datatracker.ietf.org/doc/html/rfc7636)

- [OpenID Foundation Conformance Suite](https://www.certification.openid.net/)

- [Keycloak Documentation](https://www.keycloak.org/documentation)

- [Keycloak Release Notes](https://www.keycloak.org/docs/latest/release_notes/index.html)

- [OpenID Connect Core 1.0](https://openid.net/specs/openid-connect-core-1_0.html)