merge: BFF versus SPA-direct comparison
This commit is contained in:
@@ -0,0 +1,22 @@
|
||||
# BFF vs SPA direct
|
||||
|
||||
| 항목 | SPA direct (AP1) | BFF (AP3) |
|
||||
|---|---|---|
|
||||
| OAuth client | public + PKCE | confidential + server secret |
|
||||
| token holder | browser JavaScript memory | BFF server |
|
||||
| browser credential | access/refresh token | HttpOnly session cookie |
|
||||
| XSS 영향 | 실행 중 token/API 권한 탈취 가능 | cookie 읽기는 막지만 same-origin 요청 악용 가능 |
|
||||
| CSRF | bearer header 중심이라 상대적으로 작음 | session cookie이므로 명시적 방어 필요 |
|
||||
| backend 상태 | stateless 가능 | session store 필요 |
|
||||
| logout/revocation | browser와 Keycloak 조정 | BFF session과 Keycloak logout 조정 |
|
||||
| scale-out | JWT 검증 위주 | sticky session 또는 shared store |
|
||||
|
||||
이 repository의 AP3는 Spring `oauth2Login`, confidential `bff-confidential`
|
||||
client, server-side authorized-client/token 보관, HttpOnly/SameSite session,
|
||||
CSRF token을 실제 구현한다. AP1은 token을 메모리에만 두지만 XSS가 실행되면
|
||||
현재 token을 사용할 수 있다는 경계를 E2E로 보여 준다.
|
||||
|
||||
선택은 “BFF가 항상 더 안전하다”가 아니라 threat model과 운영비의 교환이다.
|
||||
브라우저에 OAuth token을 노출하지 않는 것이 우선이고 stateful 운영을 감당할
|
||||
수 있으면 BFF, protocol과 stateless Resource Server를 직접 학습하려면 AP1이
|
||||
더 투명하다.
|
||||
Reference in New Issue
Block a user