고객사마다 다른 IdP, B2B SaaS는 어떻게 하나의 SSO로 수용할까
고객별로 다른 IdP와 프로토콜을 사용하는 B2B SaaS가 멀티 테넌트 SSO를 안전하고 확장 가능하게 설계하는 방법을 알아봅니다.
엔터프라이즈 고객에게 SSO를 제공할 때 가장 먼저 부딪히는 현실은 모든 고객이 같은 IdP를 쓰지 않는다는 점입니다. 어떤 고객은 Microsoft Entra ID를, 다른 고객은 Okta나 Google Workspace를 사용합니다. 연결 방식도 OIDC와 SAML로 나뉘고, 사용자 생성과 회수에는 SCIM을 요구하기도 합니다.
고객이 늘 때마다 제품 코드에 예외를 추가하면 초기 계약은 대응할 수 있어도 운영 복잡도와 보안 위험이 함께 커집니다. B2B SaaS에는 여러 IdP를 단순히 “연결”하는 기능보다 고객사별 인증 경계를 유지하는 멀티 테넌트 전략이 필요합니다.
하나의 공용 SSO 설정이 위험한 이유
공용 설정에 여러 고객의 도메인, 인증서, 클라이언트 비밀을 함께 넣으면 한 고객의 변경이 다른 고객의 로그인에 영향을 줄 수 있습니다. 사용자 이메일만 보고 테넌트를 결정하는 방식도 도메인 소유권을 확인하지 않으면 잘못된 조직으로 연결될 위험이 있습니다.
먼저 고객사별로 연결 설정, 허용 도메인, 프로토콜, MFA 정책, 관리자 권한을 분리해야 합니다. 도메인 등록 전에는 DNS 등을 통해 소유권을 확인하고, 자세한 원칙은 도메인 검증과 SSO 보안을 참고하세요.
OIDC와 SAML을 같은 운영 모델로 관리하기
프로토콜 구현은 달라도 운영 항목은 표준화할 수 있습니다. 각 연결에 다음 정보를 명시하세요.
- 소유 고객사와 담당 관리자
- 발급자·메타데이터·리디렉션 주소
- 인증서 또는 클라이언트 비밀의 만료일
- 테스트 완료 상태와 마지막 변경 이력
- 장애 시 비상 로그인 및 롤백 절차
새 앱은 OIDC가 편리한 경우가 많지만 기존 기업 환경에서는 SAML 요구가 여전히 많습니다. 선택 기준은 OIDC와 SAML 비교에서 확인할 수 있습니다.
로그인 이후의 수명주기도 연결해야 합니다
SSO 성공만으로 계정 관리가 끝나지는 않습니다. 입사자 생성, 부서 이동에 따른 권한 변경, 퇴사자 차단이 수동이면 휴면 계정과 과도한 권한이 남습니다. 고객별 SCIM 연결을 분리하고 그룹을 앱 역할에 매핑해 인증과 프로비저닝이 같은 테넌트 경계를 따르게 해야 합니다.
SSO를 지원하지 않는 기존 앱에는 SWA를 보완 수단으로 적용할 수 있지만, 비밀번호 보관 정책과 접근 로그를 별도로 관리해야 합니다. 또한 관리자와 고위험 작업에는 MFA를 적용해 연동된 IdP의 정책 공백을 줄이는 것이 좋습니다.
고객 추가가 개발 프로젝트가 되지 않게 하세요
확장 가능한 구조에서는 고객 관리자가 자신의 OIDC/SAML 연결을 설정하고, 검증 테스트를 거쳐 활성화하며, SaaS 운영자는 전체 상태와 감사 이력을 확인합니다. 고객별 격리 원칙은 멀티 테넌트 IdP 격리에서 더 자세히 설명합니다.
AxiPass는 SaaS 기업이 고객사별 OIDC/SAML SSO, SCIM, MFA와 SWA 연결을 하나의 멀티 테넌트 환경에서 운영하도록 지원합니다. 고객마다 다른 IdP를 제품 코드의 예외가 아니라 표준화된 연결 단위로 관리해 엔터프라이즈 온보딩을 빠르고 안전하게 만드세요.