9.2 KiB
Back-Channel Logout 통합 가이드
이 문서는 Baron SSO와 연동하는 RP들이 Back-Channel Logout을 어떻게 처리하는지 한 곳에서 정리합니다.
핵심은 다음 두 가지입니다.
- Baron SSO가 RP로 보내는 요청 형식은 공통입니다.
- RP가 그 요청을 받아 세션을 찾고 지우는 내부 로직은 RP 유형에 따라 달라질 수 있습니다.
결론
Baron SSO는 모든 RP에 대해 같은 방식으로 POST /backchannel-logout를 보냅니다.
Content-Type: application/x-www-form-urlencoded- body:
logout_token=<jwt> - 검증용 공개키는
GET /api/v1/auth/backchannel/jwks.json
차이는 Baron이 보낸 뒤 RP 내부에서 세션을 어디서 찾고 어떻게 파기하느냐입니다.
PKCE RPserver-side-app RPheadless login RP는PKCE기반 custom login UI 변형
Polling과 Session Management
polling에 가장 가까운 OIDC 개념은 Back-Channel Logout이 아니라 OpenID Connect Session Management입니다.
이 방식은 RP 서버가 OP 서버를 주기적으로 polling하는 구조가 아니라, RP 브라우저 화면 안에서 OP의 check_session_iframe과 통신하면서 OP 세션 상태 변화 여부를 확인하는 구조입니다.
개념적으로는 다음과 같습니다.
RP 브라우저 화면
↓ 주기적으로 확인
OP check_session_iframe
↓
changed / unchanged / error
↓
changed면 RP가 재인증 또는 로그아웃 처리
즉, 이건 브라우저 기반 front-channel/iframe 방식이지, RP 서버가 OP 서버에 주기적으로 polling하는 Back-Channel Logout 방식은 아닙니다.
Session Management를 쓸 때의 의미
Session Management를 도입하면 RP는 브라우저를 통해 OP 세션 상태 변화를 감지하고, 상태가 바뀌면 로컬 세션을 정리하거나 재인증을 유도합니다.
일반적인 흐름은 다음과 같습니다.
- 로그인 시 RP가 OP 세션 식별에 필요한 정보를 보관합니다.
- RP 화면이
check_session_iframe상태를 주기적으로 확인합니다. - OP 세션이 바뀌면
changed를 받습니다. - RP가 로컬 세션을 삭제하거나 재인증을 시작합니다.
Session Management 기반 로직 구성 예시
sequenceDiagram
autonumber
participant Browser as RP Browser
participant RP as RP App
participant IFrame as OP check_session_iframe
participant Store as RP Session Store
loop 주기적 확인
Browser->>IFrame: session state check
IFrame-->>Browser: changed / unchanged / error
alt unchanged
Browser->>RP: 로컬 세션 유지
else changed
Browser->>RP: 재인증 또는 로그아웃 유도
RP->>Store: session destroy
RP->>RP: 세션 매핑 제거
else error
Browser->>RP: 재시도 또는 안전 로그아웃
end
end
권장 구성은 다음과 같습니다.
- 로그인 시
sid또는sub를 RP 세션에 저장합니다. - RP 화면이
check_session_iframe상태를 주기적으로 확인합니다. changed가 오면 RP가 로컬 세션을 삭제하거나 재인증을 시작합니다.error가 반복되면 안전하게 로그아웃 처리하는 정책을 둘 수 있습니다.
이 방식은 Back-Channel Logout과 별개로 설계하는 것이 좋습니다.
공통 시퀀스
아래 흐름은 세 RP에 공통입니다.
sequenceDiagram
autonumber
participant Baron as Baron SSO
participant RP as RP
participant JWKS as Baron Back-Channel JWKS
participant Store as RP Session Store
Baron->>RP: POST /backchannel-logout\nlogout_token=<jwt>
RP->>RP: logout_token 추출
RP->>JWKS: JWKS로 서명 검증
JWKS-->>RP: public key
RP->>RP: iss / aud / events / nonce / jti 검증
RP->>RP: sid 또는 sub로 세션 탐색
RP->>Store: session destroy
Store-->>RP: 삭제 완료
RP->>RP: 세션 매핑 제거
RP-->>Baron: 200 OK
공통 전송 규칙
Baron SSO에서 RP로 보내는 형식은 동일합니다.
| 항목 | 값 |
|---|---|
| HTTP method | POST |
| Path | /backchannel-logout |
| Content-Type | application/x-www-form-urlencoded |
| Body | logout_token=<jwt> |
| 검증 JWKS | /api/v1/auth/backchannel/jwks.json |
전송 로직은 Baron 쪽에서 공통으로 처리됩니다.
RP별 차이
세 RP는 모두 logout_token을 받아 검증하고 세션을 지운다는 점은 같습니다.
다만 세션이 만들어지는 시점과 저장 방식이 다릅니다.
| 항목 | PKCE RP | server-side-app RP | headless login RP |
|---|---|---|---|
| 로그인 성격 | Authorization Code + PKCE | confidential client | PKCE 기반 custom login UI |
| 백채널 수신 endpoint | 필요 | 필요 | 필요 |
| 세션 저장 구조 | 앱 서버/BFF/브라우저 연동에 따라 다양 | 서버 세션 중심 | headless 로그인 이후 로컬 세션 바인딩 |
sid/sub 매핑 |
callback 이후 저장 | callback 이후 저장 | login 성공 이후 저장 |
| 세션 파기 방식 | 매핑된 session id 삭제 | 매핑된 session id 삭제 | 매핑된 session id 삭제 |
| 차이의 핵심 | 서버 endpoint가 없으면 처리 불가 | 서버 세션 구조와 잘 맞음 | 로그인 진입점만 다르고 로그아웃 처리는 공통 패턴 |
RP별 처리 설명
PKCE RP
PKCE RP는 브라우저 기반 로그인 흐름을 사용하지만, 백채널 로그아웃을 받으려면 반드시 서버 endpoint가 있어야 합니다.
이유는 Baron이 브라우저가 아니라 RP 서버로 직접 POST를 보내기 때문입니다.
처리 순서:
- callback 이후
sid또는sub를 RP 세션과 바인딩합니다. - Baron이
POST /backchannel-logout를 보냅니다. - RP가
logout_token을 검증합니다. sid우선, 실패 시sub로 세션을 찾습니다.- 세션 스토어에서 해당 세션을 삭제합니다.
주의:
- 순수 frontend-only PKCE 앱은 백채널 로그아웃을 직접 받을 수 없습니다.
- 서버나 BFF가 있어야 합니다.
server-side-app RP
server-side-app RP는 confidential client이므로, 서버 세션 구조와 백채널 로그아웃이 자연스럽게 맞습니다.
처리 순서:
- OIDC Authorization Code 로그인과 callback을 처리합니다.
- callback 이후
sid또는sub를 서버 세션과 바인딩합니다. - Baron이
POST /backchannel-logout를 보냅니다. - RP가
logout_token을 검증합니다. - 세션 매핑을 찾아 직접 파기합니다.
이 유형은 PKCE보다 세션 관리가 명확해서 문서화와 운영이 단순합니다.
headless login RP
headless login은 별도의 로그아웃 타입이 아니라 PKCE 계열의 로그인 변형입니다.
즉, 로그인 시에는 custom login UI가 있고 RP backend가 headless login API를 호출하지만, 백채널 로그아웃은 결국 동일한 패턴으로 처리합니다.
처리 순서:
- headless login 성공 후
sid또는sub를 RP 세션에 바인딩합니다. - Baron이
POST /backchannel-logout를 보냅니다. - RP가
logout_token을 검증합니다. sid또는sub로 세션을 찾습니다.- 세션 스토어에서 해당 세션을 삭제합니다.
핵심은 로그인 진입점만 다르고, 로그아웃 처리 패턴은 PKCE RP와 같습니다.
공통 검증 규칙
RP는 아래 항목을 검증해야 합니다.
- JWT 서명 검증
iss가 Baron OIDC issuer와 일치aud에 현재 RPclient_id포함iat존재jti존재events에http://schemas.openid.net/event/backchannel-logout포함nonce가 없어야 함sid또는sub가 있어야 함
권장 사항:
jtireplay 방지- 시계 오차 허용
- 검증 실패 시
400
세션 파기 규칙
Back-Channel Logout은 현재 브라우저 요청의 req.session.destroy()만으로는 부족합니다.
반드시 세션 저장소에서 실제 세션 id를 찾아 직접 파기해야 합니다.
권장 우선순위:
sid로 탐색sid가 없거나 매칭 실패 시sub로 fallback
공통 테스트 포인트
- RP 로그인 후
sid/sub -> sessionId매핑이 생성되는지 확인 - Baron이
POST /backchannel-logout를 실제로 보내는지 확인 - RP가
logout_token을 검증하는지 확인 - 세션 스토어에서 세션이 삭제되는지 확인
- 동일한
logout_token재전송 시 replay 방지가 동작하는지 확인