---
id: 3f886154-1b85-407b-bda4-57d28370e745
kind: REFERENCE
slug: oauth-oidc-pattern-selection-criteria
title: OAuth/OIDC 인증 패턴 선택 기준
topic: OAuth/OIDC 인증 경계
project: KeyCloak Patterns
status: 게시 전
version: 10
studio: "https://hyeonworks.com/studio/documents/3f886154-1b85-407b-bda4-57d28370e745/edit"
---

# OAuth/OIDC 인증 패턴 선택 기준

SPA, Mediator, BFF, OAuth2-Proxy는 브라우저의 access token 사용 여부, Resource Server 호출 주체, server-side 인증 상태, 보호 자원이 검증하는 credential, CSRF 처리 위치가 서로 다르다. 패턴 선택에서는 이 다섯 항목을 요구사항과 운영 환경에 맞춰 비교한다.

## 관계

- **SPA에서 토큰을 직접 관리하면서 드러난 Browser Credential 경계**
  브라우저가 code 교환과 token 보관, API 호출을 모두 맡는다.
- **Mediator가 Refresh Token을 관리하고 Access Token을 Browser에 전달하는 구조**
  mediator가 refresh token을 관리하고 브라우저가 access token으로 API를 직접 호출하는 구성을 확인했다.
- **BFF에서 OAuth Token을 관리할 때 Session과 CSRF를 처리한 과정**
  BFF가 code 교환, token 보관, Resource Server 호출을 모두 처리하는 구성을 확인했다.
- **Forward-Auth에서 Client가 보낸 Identity Header를 신뢰하면 안 되는 이유**
  인증이 edge로 가면 보호 자원이 검증하는 것이 JWT에서 헤더로 바뀐다.
- **인증 구조를 보안 성숙도 단계로 취급하지 않는다**
  이 기준의 첫 항목을 프로젝트 결정으로 굳힌 기록이다.

## 목적

브라우저에 token이 덜 보이는 순서는 있다. 그 순서를 보안 등급으로 쓰면 판단이 틀린다.

BFF는 브라우저 token을 없애지만 server session과 공유 저장소를 만든다. Forward-Auth는 애플리케이션의 token custody를 줄이지만 edge 헤더 신뢰와 network 경계를 만든다. 새로 생긴 쪽을 감당할 수 없는 환경이면 앞 구조가 더 안전하다.

번호가 아니라 배치를 본다.

## 규칙

### 1. 다섯 항목으로 구조를 비교한다

구조를 비교할 때는 브라우저 token 전달, Resource Server 호출 주체, server-side 상태, Resource Server의 검증 대상, CSRF 처리 위치를 확인한다.

브라우저가 access token을 받나
SPA : o   Mediator : o   BFF : x   Forward-Auth : x

브라우저가 보호 자원을 직접 부르나
SPA : o   Mediator : o   BFF : x   Forward-Auth : x

server-side token 상태가 있나
SPA : x   Mediator : o   BFF : o   Forward-Auth : proxy session

보호 자원이 무엇을 검증하나
SPA : 서명된 JWT   Mediator : 서명된 JWT   BFF : 서명된 JWT   Forward-Auth : edge가 붙인 헤더

cookie가 credential이면 CSRF 검증이 어디에 붙나
SPA : 해당 없음   Mediator : session endpoint   BFF : 상태 변경 endpoint   Forward-Auth : proxy cookie 기준

호출 주체와 credential 저장 방식을 정한 뒤에는 401/403, token 갱신 실패, logout을 어느 계층에서 처리할지 정한다.

### 2. 피해야 할 조건을 먼저 확인한다

정책상 브라우저에 token을 둘 수 없으면 memory에만 두는 보관은 답이 아니다. backend 직접 경로나 헤더 덮어쓰기를 닫을 수 없으면 edge에 인증을 맡기지 않는다. 이 조건에 걸리면 다른 항목은 볼 필요가 없다.

### 3. 선택 조건과 운영 부담을 함께 기록한다

선택 결과만 적지 않고 어떤 요구에서 해당 패턴을 선택했는지와 적용하기 어려운 조건도 함께 기록한다.

### 4. 이름으로 운영 속성을 추정하지 않는다

BFF나 forward-auth라는 이름은 배치를 말할 뿐이다. 공유 저장소와 장애 복구, session failover, secret 교체가 갖춰져 있는지는 매번 따로 확인한다.

### 5. 옮기는 것은 업그레이드가 아니다

패턴을 바꾸면 credential을 저장하고 전달하고 검증하는 주체도 함께 바뀐다. edge header가 계속 늘어나 애플리케이션 도메인 정보까지 전달해야 한다면 BFF에서 인가와 API 조합을 처리하는 구성을 다시 검토할 수 있다.

## 적용 조건

- 인증 구조를 처음 고를 때
- 한 구조에서 다른 구조로 옮기려 할 때
- 구조를 문서로 비교할 때
- 이름만 보고 고른 구조를 다시 검토할 때

## 예외

- 요구가 하나로 좁혀지면 비교가 필요 없다. 브라우저에 token을 둘 수 없고 backend가 API를 조합해야 하면 선택지는 하나다.
- 학습이나 시연이 목적이면 운영 속성 비교를 하지 않아도 된다. 그때는 학습 환경이라고 문서에 적어 둔다.

## 예시

- SPA : 브라우저가 code 교환과 token 보관, API 호출을 모두 맡는다
- Mediator : refresh token은 server에 있고 access token은 응답 본문으로 브라우저에 간다
- BFF : server가 code 교환·token 관리·API 호출을 담당하고 브라우저는 session cookie로 BFF를 호출한다
- Forward-Auth : edge가 인증하고 upstream은 edge가 붙인 헤더를 본다