refactor: 문서 개선 중

.run/keycloak-four-patterns/records/question-edge-authorization-scope.md

@@ -0,0 +1,83 @@
+---
+id: 7ff40767-a00b-4db2-98f6-0cdfce8c8936
+kind: QUESTION
+slug: edge-authorization-scope
+title: Forward-Auth 구조에서 Application Authorization을 어디까지 Edge에 둘 것인가
+topic: OAuth/OIDC 인증 경계
+project: KeyCloak Patterns
+status: 게시 전
+version: 9
+questionStatus: OPEN
+studio: "https://hyeonworks.com/studio/documents/7ff40767-a00b-4db2-98f6-0cdfce8c8936/edit"
+---
+
+# Forward-Auth 구조에서 Application Authorization을 어디까지 Edge에 둘 것인가
+
+지금 edge는 user와 email만 전달하고 upstream은 role 판단을 하지 않는다. 다음 요구가 들어왔을 때 role까지 헤더로 보낼지, 아니면 인가를 애플리케이션으로 되돌릴지 정하지 않았다.
+
+## 관계
+
+- **Forward-Auth에서 Client가 보낸 Identity Header를 신뢰하면 안 되는 이유**
+  edge가 user와 email만 전달한다는 사실의 출처다.
+- **Forward-Auth에서 Identity Header를 신뢰하기 위한 조건**
+  헤더 allowlist와 검증 조건이 이 기준에 있다.
+- **BFF 인증 구조 설계 기준**
+  되돌리는 선택지의 기준이 이 문서다.
+
+## 사실
+
+- 지금 edge 응답은 user와 email만 전달한다. role과 groups, tenant, 인증 방식, token 만료는 전달하지 않는다.
+- upstream의 identity endpoint는 role 판단을 하지 않고 누가 왔는지만 응답에 담는다.
+- internal token 검사가 controller 한 곳에 있고 security 설정은 그 경로 전체를 permitAll로 둔다. 새 endpoint에는 보호가 따라오지 않는다.
+- Nginx는 client가 보낸 동명 헤더를 merge하지 않고 덮어쓴다. 늘리는 헤더도 같은 처리를 받아야 한다.
+- upstream은 JWT를 입력으로 받지 않아서 헤더로 온 값을 스스로 검증할 수단이 없다.
+
+## 가정
+
+- 헤더 종류가 늘어나면 정해야 할 계약도 함께 늘어난다.
+- role이 바뀌는 시점과 요청이 오는 시점이 달라서 그 사이에 들어온 요청은 옛 값을 본다.
+
+## 미지수
+
+- 다중 값 role을 어떤 구분자와 escaping으로 보낼지. 값 안에 그 구분자가 들어오면 어떻게 되는지.
+- 헤더 크기 상한을 넘으면 무엇이 먼저 깨지는지. proxy가 자르는지 요청 자체가 거부되는지.
+- role이 바뀌었을 때 proxy session과 downstream 인가가 언제 따라가는지. 권한 회수가 몇 분 뒤에 반영되는지.
+- upstream이 헤더 존재만 볼지 값과 service identity까지 볼지.
+
+## 제약
+
+- 전달할 헤더는 allowlist로 고정해야 하고 client가 보낸 동명 헤더는 언제나 덮어써야 한다.
+- internal token 검사가 controller 한 곳에만 있다. 헤더를 늘리기 전에 이 검사를 공통 경계로 옮기는 것이 먼저다.
+- upstream을 고칠 수 없어서 이 구조를 골랐다면 BFF로 되돌리는 선택지는 없다.
+
+## 선택지
+
+### 1. 현재 — 인증만 edge에 둔다
+
+헤더가 user와 email 둘로 고정돼 있어서 계약이 가장 작고 크기 상한 문제도 생기지 않는다. 인가는 upstream이 자기 저장소로 해결한다. 서비스마다 권한 조회를 따로 붙여야 한다.
+
+### 2. 다음 후보 — role 전달까지 edge에 둔다
+
+공통 role을 한 곳에서 주면 서비스마다 권한을 조회하지 않아도 된다. 이 선택을 하면 다중 값 직렬화와 크기 상한, 갱신 시점 계약을 먼저 정해야 한다. upstream은 그 값을 검증할 수단이 없어서 edge가 틀리면 그대로 틀린다.
+
+### 3. 보류 — tenant와 인가 판단까지 edge에 둔다
+
+tenant는 잘못 들어간 값 하나가 다른 조직의 데이터를 그대로 열어 준다. 이 값만은 upstream이 다시 확인할 수단을 함께 설계해야 해서 지금 구성으로는 감당할 수 없다. 인가 판단까지 옮기면 edge가 애플리케이션 도메인을 알아야 하고 정책이 바뀔 때마다 edge를 배포하게 된다.
+
+### 4. 경계가 커지면 — BFF로 되돌린다
+
+role·tenant 정보를 edge header로 계속 확장하지 않고 BFF가 필요한 정보를 조회해 인가와 API 조합을 처리하는 선택지도 있다. 이 경우 BFF session, CSRF 검증, shared store 운영이 다시 필요하다.
+
+## 다음 검증
+
+upstream이 실제로 요구하는 claim을 먼저 적는다. 그 목록을 놓고 아래를 본다.
+
+1. 전달하려는 claim이 계속 늘어나는가.
+2. role이나 tenant 변경이 즉시 반영돼야 하는가.
+3. 정책이 애플리케이션 도메인을 알아야 하는가.
+4. 헤더 값이 인가 판단의 근거가 되는가.
+5. 서비스별 정책 차이가 커지는가.
+
+2번부터 5번 중 하나라도 그렇다면 헤더를 늘리는 방향이 아니라 되돌리는 방향을 본다.
+
+role을 헤더로 실은 구성을 먼저 만들어 다중 값과 크기 상한을 넣고 무엇이 먼저 깨지는지 확인한다. role을 바꾼 뒤 몇 번째 요청부터 반영되는지도 잰다.