OIDC(OpenID Connect) Backchannel 로그아웃

OIDC(OpenID Connect)는 세 가지 다른 형태의 로그아웃을 지정하며 그 중 두 가지는 FrontChannel 통신을 사용합니다. OIDC Backchannel 로그아웃은 Backchannel 통신을 사용하는 로그아웃 메커니즘입니다

 

Front Channel 통신은 요청이 사용자 에이전트(즉, 브라우저를 통해 전달되는 경우)이고 BackChannel 통신은 요청이 서버 간의 직접 네트워크 링크를 사용하여 전달되는 경우입니다.

백채널 로그아웃?

OpenID Connect 백채널 로그아웃은 RP(Relying Party) 응용 프로그램이 사용자 에이전트를 거치지 않고 RP와 OP(OpenID 공급자, OpenID Provider) 간에 직접 전달되는 로그아웃 요청으로 로그아웃 되는 메커니즘입니다.

이 로그아웃 메커니즘은 최종 사용자의 브라우저 활동에 의존하지 않기 때문에 프론트 채널 통신을 사용하는 다른 방법보다 훨씬 덜 취약합니다. 이것은 OIDC 로그아웃을 위한 최선의 옵션처럼 보일 수 있지만 시스템에 새로운 요구 사항을 부과하므로 모든 시나리오에 해당되는 것은 아닙니다.

 

개요

• RP 또는 OP가 로그아웃 작업을 트리거하면 OP는 OP에서 동일한 사용자의 세션을 공유하는 모든 RP를 찾습니다.
• 그런 다음 OP는 각 RP에 대한 관련 클레임을 포함하는 로그아웃 토큰이라는 특수 JWT 토큰을 생성하고 모든 RP의 로그아웃 끝점에 로그아웃 토큰과 함께 로그아웃 요청을 보냅니다.
• Logout Token을 받으면 RP는 토큰을 많이 검증하고 특정 사용자의 세션을 무효화합니다.

 

• 예를 들어 End User가 Facebook(OpenID 공급자) 을 사용하여 3rd Party App(Relying Party) 에 로그인합니다 . 따라서 Facebook에서 End User가 로그아웃할 때 Facebook은 로그아웃 토큰 을 통해 타사 앱에 로그아웃 요청 을 보내야 합니다 .
• 3rd Party App이 Facebook에서 로그아웃 요청을 받으면 로그아웃 토큰을 확인하고 해당 End User의 세션을 종료합니다.
• 이제 사용자는 Facebook에서만 로그아웃을 호출했지만, 동시에 해당 3rd Party App에서도 로그아웃했습니다.

로그아웃 토큰

로그아웃 토큰은 OpenID Connect의 ID 토큰과 매우 유사한 JWT이며 보안 이벤트 토큰 (Security Event Token) 의 한 유형이기도 합니다 . 여기에는 RP 애플리케이션이 로그아웃 요청을 검증 및 확인하고 특정 사용자에 대한 로그아웃 프로세스를 트리거하는 데 필요한 로그아웃 작업과 관련된 클레임이 포함됩니다.

 

아래의 클레임은 로그아웃 토큰 내에서 사용됩니다.

• iss — Issuer Identifier. 토큰(OP)을 생성한 엔터티의 대소문자 구분 URL입니다. 필수 필드입니다.
• sub — Subject Identifier. 발급자가 고객에게 할당한 고유 식별자입니다. 이 필드는 선택 사항입니다.
• aud — Audience. 로그아웃 토큰이 사용되는 클라이언트 목록입니다. 필수 필드입니다.
• iat — Issued At Time(발행 시간). 토큰이 발행된 시간입니다. 이 필드도 필수입니다.
• jti — JWT ID. 토큰의 고유 식별자입니다. 이는 로그아웃 토큰 재생을 방지하는 데 사용됩니다. 이 필드는 필수입니다.
• events — 멤버 이름이 " http://schemas"인 JSON 객체입니다. openid.net/event/backchannel-logout ". 멤버의 값은 빈 JSON 객체여야 합니다. 이것은 이 JWT가 로그아웃 토큰임을 선언하기 위한 것입니다. 이 필드는 필수입니다.
• sid — 세션 ID. RP에서 사용자 에이전트의 세션에 대한 식별자입니다. 이 필드는 선택 사항입니다.

sid 및 sub 클레임은 선택 사항으로 간주 되지만 로그아웃 토큰은 클레임 중 하나를 포함해야 하며 둘 다 포함할 수 있습니다. sid 클레임이 없으면 RP는 iss 및 sub 클레임으로 식별되는 최종 사용자의 모든 세션을 로그아웃해야 합니다 .

보안 상의 이유로 nonce 클레임은 로그아웃 토큰에 포함되어서 는 안 됩니다. 로그아웃 토큰 은 디지털 서명 해야 하며 암호화할 수도 있습니다( 사양 참조 ) .

다음은 로그아웃 토큰의 예입니다.

 

작동 원리

백채널 로그아웃 프로세스는 OP가 OP에 등록된 RP의 백채널 로그아웃 URI에 HTTP(S) POST 로그아웃 요청을 보낼 때 시작됩니다. 이러한 로그아웃 요청은 다음과 같습니다.

 

로그아웃 요청을 받으면 RP는 로그아웃 작업이 합법적인지 확인하기 위해 필요한 유효성 검사 단계를 수행해야 합니다. 유효성 검사 단계는 여기 에 설명되어 있습니다. 유효성 검사 단계에서 문제가 발생하면 로그아웃 요청이 거부되고 RP는 OP에 HTTP 400을 반환해야 합니다.

 

검증이 완료되고 성공하면 RP는 로그아웃 토큰에서 iss 및 sub 클레임으로 식별된 세션을 찾고 해당 세션과 관련된 모든 상태를 지워야 합니다. offline_access 속성이 없는 새로 고침 토큰도 취소해야 합니다. RP가 이러한 작업을 수행하는 메커니즘은 구현에 따라 다르며 사양에 의해 엄격하게 정의되지 않습니다.

 

RP가 다운스트림 로그인 세션을 제공하는 OP이기도 ​​한 경우 로그아웃 요청을 받으면 로그인한 모든 다운스트림 RP에도 로그아웃 요청을 생성해야 합니다.

 

로그아웃이 성공하면 RP는 HTTP 200 OK로 OP에 다시 응답하고 백채널 로그아웃 프로세스가 최종적으로 완료됩니다. 

BackChannel 로그아웃 설정 시, sid 값을 이용한 구현 사례

1. SSO 인증 세션 로그인 처리 시, sid 클레임 값을 연동 대상 시스템의 세션 ID와 매핑 저장

   - 필자의 경우, 실제 프로젝트 구현 시, 별도 테이블 등에 저장 관리 (SID, JSESSIONID, 서버 IP, 로그인 일자/시간 등)

   - BackChannel 로그아웃이 호출될 경우, 로그아웃 토큰 상의 고유(Unique)값으로 사용할 수 있는 sid 클레임 값과

     로그아웃을 시킬 해당 WAS의 세션 ID (JSessionID) 매핑하여 저장함

   - 주요 고려 사항으로, 일반적으로 대부분의 WAS 서버를 이중화 구성함에 따라 해당 WAS의 세션 클러스터링 여부 확인 필수

   - WAS 서버가 세션 클러스터링된 경우라면, JSESSIONID가 공유되어 상관없지만,   
   - 엔터프라이즈 버전이 값이 비쌈에 따라 클러스터링 기능을 제공하지 않을 경우에는 JSESSIONID을 생성한 서버 IP도 해당 테이블의 PK 로 설정하여 설계 (SID, JSESSIONID, 서버 IP) 했었음

   - 이중화 되지 않고 서버 한 대가 단독으로 서비스 제공 시에는 굳이 테이블에 저장하지 않고, Map 을 이용하여 구현하기도 함

2. BackChannel 로그아웃을 처리하기 위한 별도 로그아웃 페이지 개발 필요

   - 통합 로그아웃 시에 SSO 서버에서 해당 BackChannel 로그아웃 페이지를 호출함

   - 페이지 호출 시에 해당 SSO 서버의 SID 값을 전달함

   - 로그아웃 page 에서 전달받은 SID 값과 매핑되는 JSESSIONID 값을 별도 세션 정보 저장소에 검색

   - 검색한 서버 IP 와 JSESSIONID 값을 이용하여 해당 서버 IP의 세션을 삭제 처리함

    

장점과 단점

장점

Backchannel 로그아웃 메커니즘은 Frontchannel 통신이 포함되지 않으므로 다른 방법보다 더 안정적입니다. 로그아웃 요청의 성공은 RP의 브라우저 세션 활동에 달려 있지 않습니다.

단점

• 백채널 통신을 위해 서버 간에 추가 네트워크 링크를 설정해야 하므로 시스템에 새로운 요구 사항이 부과됩니다. RP의 백채널 로그아웃 EndPoint는 모든 OP에서 도달할 수 있어야 하며 공용 OP를 사용할 때 방화벽이나 NAT 뒤에 있을 수 없습니다.
• 쿠키 및 HTML5 저장소에 저장된 세션 상태 데이터는 백채널 통신에 사용할 수 없습니다. 따라서 당사자 간에 상태를 명시적으로 전달해야 합니다.
• 프론트채널 방식에서 로그아웃은 단순히 쿠키와 HTML5 저장 상태를 지우는 것입니다. 백채널 로그아웃에서는 RP가 로그아웃 요청을 받으면 사용자 세션을 종료하기 위한 응용 프로그램별 방법을 구현해야 하므로 더 복잡합니다.
• 위의 실제 구현 사례와 같이 SID, JSESSIONID, 서버 IP를 조합하여 설계한 테이블 구성 및 세션 로그아웃을 처리하도록 추가적인 개발 들이 필요합니다.