비교 - BFF 인증 vs 클라이언트 직접 JWT¶
비교 대상¶
- BFF 인증: 브라우저는
sid쿠키만 유지하고, 별도 BFF 서비스가 JWT 보관, 주입, 갱신을 맡는 방식 - 클라이언트 직접 JWT: 브라우저나 데스크톱 클라이언트가 직접 Access Token과 Refresh Token을 보유하고 API에 붙는 방식
핵심 차이¶
| 항목 | BFF 인증 | 클라이언트 직접 JWT |
|---|---|---|
| 강점 | JWT 브라우저 미노출, 세션 중앙 관리, Silent Refresh 일원화 | 구조 단순성, 중간 계층 감소, 초기 구현 속도 |
| 약점 | BFF와 Redis 운영 복잡성 증가, 추가 서비스 의존성 | 토큰 노출면 확대, 갱신 로직 분산, 프론트엔드 보안 부담 증가 |
| 적합한 역할 | 기업 데이터와 민감 판단 결과가 얽힌 B2B 웹 제품 | 단순한 퍼블릭 API 소비나 가벼운 클라이언트 실험 |
| 실패 시 위험 | BFF 장애 시 인증 경로 전체가 흔들림 | 탈취·오용 위험, 브라우저 보안 사고 영향 확대 |
이 저장소 맥락에서의 결론¶
chemical/spec.md는 브라우저와 백엔드 서비스 사이에 독립 BFF를 두는 구조를 명시적으로 채택합니다. 이는 단순한 구현 취향이 아니라, 테넌트 격리와 CBI 보호를 전제로 하는 B2B 화학 규제 SaaS에서 브라우저 노출면을 줄이기 위한 보안 선택으로 읽는 편이 맞습니다. 따라서 이 문맥에서는 클라이언트 직접 JWT보다 BFF 인증이 기본값에 가깝습니다.
언제 균형이 깨지는가¶
- BFF가 과도하게 비대해지면 단순 프록시를 넘어 병목과 장애 지점이 됩니다.
- 클라이언트 직접 JWT를 허용하면 편의성은 늘지만, 토큰 관리와 보안 책임이 프론트엔드로 새어 나갑니다.
- 가장 중요한 것은 "누가 토큰을 들고 있는가"와 "누가 갱신 책임을 지는가"를 구조적으로 분리하는 것입니다.