87 lines
4.9 KiB
JSON
87 lines
4.9 KiB
JSON
{
|
|
"title": "브라우저 토큰에서 엣지 세션까지: Keycloak 인증 패턴 네 가지의 경계 설계",
|
|
"document_type": "technical_blog",
|
|
"language": "ko-KR",
|
|
"audience": {
|
|
"roles": [
|
|
"Keycloak을 애플리케이션에 통합하려는 백엔드·프론트엔드 개발자",
|
|
"브라우저 인증 경계와 배포 구조를 결정해야 하는 아키텍트"
|
|
],
|
|
"prior_knowledge": [
|
|
"OAuth 2.0 Authorization Code 흐름의 기본 개념",
|
|
"브라우저 쿠키와 bearer token의 기본 차이",
|
|
"reverse proxy와 Spring Security의 역할"
|
|
],
|
|
"needs": [
|
|
"AP1부터 AP4까지 책임 경계가 어떻게 이동하는지 이해",
|
|
"각 패턴의 로그인과 인증 후 API 요청을 실제 클래스·메서드·설정 단위로 끝까지 추적",
|
|
"HTTP 입력, 중간 token·session·header 변환, 다음 hop의 입력과 최종 응답을 구분",
|
|
"환경 제약에 맞는 패턴을 고를 비교 기준",
|
|
"성공 경로뿐 아니라 401·403과 현재 구현 공백까지 포함한 경계 검증",
|
|
"각 선택의 비용과 반드시 함께 둘 가드레일"
|
|
]
|
|
},
|
|
"reader_goal": "네 패턴을 보안 등급이 아니라 OAuth 코드·토큰·세션·신뢰 헤더의 소유 위치로 비교하고 자신의 환경에 맞는 Keycloak 통합 경계를 선택할 수 있다",
|
|
"core_message": "네 패턴의 차이는 로그인 화면이 아니라 OAuth 책임을 어디에 둘 것인가에 있다. 브라우저에서 mediator와 BFF를 거쳐 edge로 책임을 이동할수록 브라우저의 토큰 노출은 줄지만 서버 상태, CSRF, 프록시 헤더 신뢰 같은 다른 비용과 가드레일이 생긴다.",
|
|
"scope": [
|
|
"develop-keycloak-pattern1부터 develop-keycloak-pattern4까지의 브라우저 인증 구조",
|
|
"AP1 SPA direct, AP2 token mediator, AP3 BFF, AP4 edge forward-auth의 흐름",
|
|
"각 패턴의 선택 맥락, 대안, 수용 비용, 가드레일과 저장소 내 검증",
|
|
"Google federation이 네 패턴과 맺는 공통 관계"
|
|
],
|
|
"non_scope": [
|
|
"Keycloak 설치를 처음부터 따라 하는 튜토리얼",
|
|
"모든 조직에 적용되는 단일 최적 패턴",
|
|
"실제 Google 계정과 운영 트래픽을 사용한 운영 검증",
|
|
"성능·부하·장애 복구 수치 비교"
|
|
],
|
|
"prerequisites": [
|
|
"Authorization Code, PKCE, access token, refresh token, HttpOnly cookie의 역할을 구분할 수 있음"
|
|
],
|
|
"required_topics": [
|
|
"패턴을 가르는 공통 질문: 누가 OAuth client이고 브라우저가 무엇을 보유하는가",
|
|
"AP1 public SPA와 PKCE, resource server, issuer·audience·role 검증",
|
|
"AP1 로그인 callback과 token set의 memory 저장, Bearer API 요청과 /api/me 응답까지의 input-output",
|
|
"AP2 confidential mediator와 access-only handoff, access token 경계",
|
|
"AP2 oauth2Login callback, authorized client 저장, /token/boundary와 /token/access의 정확한 응답, browser-to-API input-output",
|
|
"AP3 oauth2Login BFF와 서버 세션, CSRF·SameSite 방어",
|
|
"AP3 /bff/api/me의 authorized-client 조회와 downstream Bearer 호출, CSRF 발급과 preferences POST의 input-output",
|
|
"AP4 oauth2-proxy와 nginx auth_request, 신뢰 헤더 스푸핑 방어",
|
|
"AP4 외부 URL에서 내부 auth subrequest와 /edge/me로 이어지는 URL·cookie·identity header 변환과 input-output",
|
|
"각 패턴에서 browser, mediator 또는 BFF, edge, Resource Server가 실제로 보유하고 전달하는 데이터 목록",
|
|
"각 패턴의 실제 클래스·메서드·설정 호출 순서와 성공·실패 HTTP 결과",
|
|
"브라우저 token 노출과 서버 상태 사이의 트레이드오프",
|
|
"Google은 별도 패턴이 아니라 Keycloak 앞의 upstream IdP라는 경계",
|
|
"저장소 테스트가 확인한 범위와 확인하지 못한 범위"
|
|
],
|
|
"constraints": {
|
|
"target_words": 8000,
|
|
"tone": "구체적인 요청 흐름과 설계 판단을 연결하는 직접적인 한국어 기술 블로그 문체",
|
|
"version_context": "저장소 브랜치 tip의 로컬 학습 구성: Keycloak 26.7.0, oauth2-proxy 7.15.2",
|
|
"max_heading_depth": 3,
|
|
"require_citations": true,
|
|
"allow_external_knowledge": false,
|
|
"citation_style": "hidden",
|
|
"date_policy": "only_when_material",
|
|
"style_profile": "woowahan_tech_blog_ko"
|
|
},
|
|
"forbidden_claims": [
|
|
"AP4는 AP1보다 무조건 안전하다",
|
|
"PKCE가 XSS 토큰 탈취를 막는다",
|
|
"BFF에는 CSRF 방어가 필요 없다",
|
|
"Google federation은 다섯 번째 패턴이다",
|
|
"실제 Google 운영 환경에서 검증했다"
|
|
],
|
|
"metadata": {
|
|
"owner": "architecture",
|
|
"risk": "high",
|
|
"source_repository": "keycloak-pattern",
|
|
"branch_scope": [
|
|
"develop-keycloak-pattern1",
|
|
"develop-keycloak-pattern2",
|
|
"develop-keycloak-pattern3",
|
|
"develop-keycloak-pattern4"
|
|
]
|
|
}
|
|
}
|