37 lines
1.8 KiB
Markdown
37 lines
1.8 KiB
Markdown
# AP3 · Backend-for-Frontend
|
|
|
|
## 요청과 token 경계
|
|
|
|
1. 브라우저는 BFF의 `/oauth2/authorization/keycloak`로 로그인을 시작합니다.
|
|
2. Spring `oauth2Login`은 PKCE S256 authorization code flow를 수행합니다.
|
|
3. BFF가 client secret으로 code를 교환하고 access/refresh token을 서버의
|
|
`OAuth2AuthorizedClientService`에 보관합니다.
|
|
4. 브라우저에는 OAuth token 대신 HttpOnly `AP3_SESSION` 식별자만 남습니다.
|
|
5. 브라우저가 `/bff/api/me`를 cookie로 호출하면 BFF가 access token을
|
|
`Authorization: Bearer`로 붙여 Resource Server에 fan-out합니다.
|
|
|
|
Resource Server는 `aud=keycloak-pattern-api`를 검증합니다. 브라우저에서는
|
|
8081로 직접 요청하거나 Keycloak token endpoint를 호출하지 않습니다.
|
|
|
|
학습용 구성은 단일 인스턴스 메모리에 session과 authorized client를
|
|
보관합니다. BFF를 재시작하면 세션이 사라집니다. 다중 인스턴스 운영에서는
|
|
Spring Session/Redis 같은 공유 저장소와 저장 token 암호화 정책이 필요합니다.
|
|
|
|
## CSRF와 SameSite 방어
|
|
|
|
`feature/keycloak-bff-oauth2login-session`에서는 방어 전 비교를 위해
|
|
CSRF를 끄고, 다른 origin의 자동 제출 form이 `/bff/api/preferences`
|
|
상태를 바꾸는 것을 재현합니다.
|
|
|
|
`feature/keycloak-bff-csrf-samesite-defense`에서는 다음 방어를 함께
|
|
적용합니다.
|
|
|
|
- Spring synchronizer CSRF token과 `CookieCsrfTokenRepository`
|
|
- JS가 읽는 `XSRF-TOKEN`과 요청의 `X-XSRF-TOKEN` header
|
|
- HttpOnly `AP3_SESSION` cookie의 명시적 `SameSite=Lax`
|
|
|
|
E2E는 token 없는 동일 위조 POST가 403이 되는 것, CSRF header가 있는
|
|
정상 POST는 200인 것, cross-site POST에는 AP3 session cookie가 제외되는
|
|
것을 각각 확인합니다. SameSite는 CSRF token을 대체하지 않는
|
|
defense-in-depth입니다.
|