---
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을 바꾼 뒤 몇 번째 요청부터 반영되는지도 잰다.