feat: 가상화 문서들 추가
This commit is contained in:
DongHyeonka
+18
@@ -10,6 +10,9 @@ status: 게시 전
|
||||
version: 4
|
||||
basisVersion: Keycloak 26.7.0 · oidc-client-ts
|
||||
studio: "https://hyeonworks.com/studio/documents/75c6c657-3e03-47a0-a9d0-5637fce9dd3f/edit"
|
||||
assets:
|
||||
- key: login-api-phase-split
|
||||
file: ../../../final/assets/login-api-phase-split/login-api-phase-split.svg
|
||||
sourceRevision: keycloak-patterns-lab@2026-08
|
||||
source:
|
||||
- final/document.md#문제를-어렵게-만든-제약-로그인-흐름과-api-흐름
|
||||
@@ -95,6 +98,21 @@ PKCE는 탈취된 authorization code의 교환을 어렵게 한다. 이미 발
|
||||
|
||||
`state`는 PKCE 값과 하는 일이 다르다. `state`는 돌아온 callback이 브라우저가 처음 시작한 트랜잭션의 것인지 대조하고, verifier는 code를 교환하는 주체를 authorization request를 시작한 클라이언트에 묶는다.
|
||||
|
||||
## 로그인을 끝내는 쪽과 API를 부르는 쪽이 다르다
|
||||
|
||||
code 교환이 끝나도 API 요청까지 같은 곳에서 처리되는 것은 아니다. 누가 token을 받았는지와 누가 보호 자원을 부르는지가 패턴마다 갈린다.
|
||||
|
||||
|
||||
|
||||
AP2에서는 mediator가 token을 받고 API는 브라우저가 부른다. AP3에서는 BFF가 두 일을 모두 맡는다. AP4에서는 oauth2-proxy가 code 교환과 `AP4_SESSION` 검증을 하고, Nginx가 upstream 요청과 identity header를 만든다.
|
||||
|
||||
그래서 `Browser → Keycloak → API`처럼 한 줄로 그리면 서로 다른 이동이 하나로 뭉친다. 두 구간으로 나누어 읽는다.
|
||||
|
||||
| 구간 | 여기서 무엇이 일어나나 |
|
||||
|---|---|
|
||||
| 로그인 구간 | authorization request, callback, code 교환, 로그인 상태 생성 |
|
||||
| 애플리케이션 요청 구간 | 브라우저 입력, 중간 계층의 credential 변환, 보호 자원의 검증, 최종 응답 |
|
||||
|
||||
## 클라이언트 종류에 따라 달라지는 인증
|
||||
|
||||
`spa-public`은 secret이 없는 public client다. token endpoint에서 클라이언트 인증을 하지 않고 PKCE만 사용한다.
|
||||
|
||||
+2
-3
@@ -12,7 +12,7 @@ basisVersion: Spring Security 6 CSRF · AP3 BFF 구성
|
||||
studio: "https://hyeonworks.com/studio/documents/5c8f12d5-1ead-469b-8e91-2de69401df48/edit"
|
||||
assets:
|
||||
- key: ap3-csrf-boundary
|
||||
file: ../../../final/assets/tech-log-studio/ap3-csrf-boundary.svg
|
||||
file: ../../../final/assets/ap3-csrf-boundary/ap3-csrf-boundary.svg
|
||||
sourceRevision: keycloak-patterns-lab@2026-08
|
||||
source:
|
||||
- final/document.md#선택의-이유와-지킨-경계-ap3
|
||||
@@ -63,8 +63,7 @@ Cookie: AP3_SESSION=<opaque-session-id>
|
||||
}
|
||||
```
|
||||
|
||||
:::evidence key="ap3-csrf-boundary" alt="BFF의 /bff/csrf 하나에서 두 갈래가 갈리는 그림. Set-Cookie로 나가는 CSRF 쿠키에는 가리지 않은 원본 값이 들어가고 JSON 본문에는 가린 토큰과 headerName이 들어간다. 브라우저 코드는 JSON에서 headerName만 쓰고 실제 헤더 값은 쿠키의 원본 값을 쓴다. Spring CSRF filter가 raw cookie와 raw header를 대조해 일치하면 controller로 보내고 부재나 불일치면 403을 낸다." caption="" zoom="true"
|
||||
:::
|
||||
|
||||
|
||||
## body의 token과 cookie의 값은 다르다
|
||||
|
||||
|
||||
+2
-3
@@ -12,7 +12,7 @@ basisVersion: oauth2-proxy 7.15.2 · Nginx auth_request module
|
||||
studio: "https://hyeonworks.com/studio/documents/a3493786-d3fb-4b01-b1c5-ecb23c3d5497/edit"
|
||||
assets:
|
||||
- key: ap4-edge-forward-auth-flow
|
||||
file: ../../../final/assets/tech-log-studio/ap4-edge-forward-auth-flow.svg
|
||||
file: ../../../final/assets/ap4-edge-forward-auth-flow/ap4-edge-forward-auth-flow.svg
|
||||
sourceRevision: keycloak-patterns-lab@2026-08
|
||||
source:
|
||||
- final/document.md#선택의-이유와-지킨-경계-ap4
|
||||
@@ -37,8 +37,7 @@ forward-auth는 실제 요청을 업스트림으로 넘기기 전에 별도의
|
||||
|
||||
## 요청 하나가 두 번 평가된다
|
||||
|
||||
:::evidence key="ap4-edge-forward-auth-flow" alt="브라우저에서 Nginx edge, oauth2-proxy, Spring upstream으로 이어지는 여섯 단계 흐름. AP4_SESSION을 실은 /api/edge 요청이 들어오면 Nginx가 internal /oauth2/auth로 subrequest를 보내 authenticated user와 email을 받는다. 그 값으로 만든 trusted header와 internal token을 붙여 /edge/me를 부르고, upstream이 돌려준 trusted identity JSON이 브라우저로 나간다." caption="" zoom="true"
|
||||
:::
|
||||
|
||||
|
||||
브라우저 요청이 들어와도 Nginx는 업스트림을 바로 호출하지 않는다. 업스트림은 Nginx가 요청을 최종으로 넘기는 뒤쪽 서버이고, 이 구성에서는 `app:8081`의 Spring 애플리케이션이다. 바로 넘기지 않는 것은 `location /`에 다음 지시어가 있기 때문이다.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user