95 lines
5.0 KiB
Markdown
95 lines
5.0 KiB
Markdown
---
|
|
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가 붙인 헤더를 본다
|