5.0 KiB
id, kind, slug, title, topic, project, status, version, studio
| id | kind | slug | title | topic | project | status | version | studio |
|---|---|---|---|---|---|---|---|---|
| 3f886154-1b85-407b-bda4-57d28370e745 | REFERENCE | oauth-oidc-pattern-selection-criteria | OAuth/OIDC 인증 패턴 선택 기준 | OAuth/OIDC 인증 경계 | KeyCloak Patterns | 게시 전 | 10 | 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가 붙인 헤더를 본다