멀티 테넌트 SSO, 이메일이 아닌 사용자 식별자로 연결해야 하는 이유

SSO 연동에서 가장 위험한 오해 중 하나는 “이메일이 같으면 같은 사용자”라고 보는 것입니다. 이메일은 사람이 읽기 편하지만 이름 변경, 도메인 이전, 재입사, 외부 인력 전환으로 바뀔 수 있습니다. 여러 고객사를 한 서비스에서 운영하는 B2B SaaS라면 서로 다른 테넌트에 같은 이메일이 존재할 수도 있습니다.

최근 IAM은 로그인 성공 여부를 넘어 아이덴티티 수명주기와 최소 권한을 함께 관리하는 방향으로 발전하고 있습니다. 그 출발점은 인증 결과를 정확한 테넌트와 내부 계정에 연결하는 것입니다. 잘못된 매핑은 배송 라벨의 이름만 보고 주소를 확인하지 않는 것과 같습니다.

이메일은 속성이지 영구 식별자가 아닙니다

이메일을 계정의 유일한 키로 사용하면 주소가 바뀔 때 새 계정이 생기거나, 과거 주소를 받은 다른 사람이 기존 권한을 이어받을 수 있습니다. 대소문자 정규화만으로 해결할 수 있는 문제가 아닙니다. 표시용 이메일과 변경되지 않는 외부 식별자를 분리해야 합니다.

프로토콜별 안정적인 키를 사용하세요

OIDC에서는 iss와 sub의 조합으로 사용자를 식별하는 것이 기본입니다. 같은 sub라도 발급자 iss가 다르면 다른 사용자일 수 있습니다. SAML은 신뢰하는 IdP와 SP 등록 정보의 경계 안에서 지속 가능한 NameID를 사용하고, 그 형식과 변경 정책을 합의해야 합니다. 두 프로토콜의 차이는 OIDC와 SAML 비교에서 확인할 수 있습니다.

SCIM의 externalId는 고객 디렉터리의 객체와 SaaS 내부 계정을 연결하는 데 유용합니다. 로그인 식별자와 프로비저닝 식별자를 별도로 저장한 뒤 하나의 내부 사용자에 명시적으로 연결하면 이메일 변경에도 수명주기가 끊기지 않습니다. SCIM의 역할은 SCIM 기초 가이드를 참고하세요.

테넌트 경계를 식별 키에 포함하세요

멀티 테넌트 SaaS의 내부 유일 키는 단순한 이메일이 아니라 tenant + identity provider + external subject에 가까워야 합니다. 인증 응답을 처리할 때 요청을 시작한 테넌트, 등록된 IdP, 발급자, 대상 앱을 함께 검증해야 다른 고객사의 계정과 섞이는 것을 막을 수 있습니다.

고객 도메인을 확인하는 절차도 유용하지만 도메인 소유권이 곧 사용자 동일성을 증명하지는 않습니다. 도메인 검증 보안 가이드의 통제와 사용자 식별자 매핑을 서로 다른 방어선으로 운영해야 합니다.

계정 연결과 변경에는 감사 흔적이 필요합니다

최초 연결, 식별자 변경, 수동 병합, 연결 해제는 모두 고위험 작업입니다. 작업자, 테넌트, 이전 값과 새 값, 사유, 시각을 감사 로그에 남기되 토큰이나 비밀값은 기록하지 않습니다. 자동 매핑이 모호하면 이메일로 추측하지 말고 로그인을 중단한 뒤 관리자 검토로 보내는 편이 안전합니다.

출시 전 체크리스트

• OIDC는 iss + sub, SAML은 합의된 지속형 NameID를 기준으로 삼습니다. • 내부 키에 테넌트와 IdP 경계를 포함합니다. • SCIM externalId와 로그인 식별자의 연결 규칙을 문서화합니다. • 이메일 변경, 재입사, 동일 이메일 충돌 시나리오를 테스트합니다. • 수동 계정 병합에는 승인과 감사 로그를 적용합니다.

AxiPass로 고객별 아이덴티티 경계를 일관되게 운영하세요

AxiPass는 SaaS 기업이 멀티 테넌트 환경에서 OIDC, SAML, SCIM, MFA와 SSO 미지원 앱을 위한 SWA를 함께 운영하도록 돕습니다. 고객별 연동 설정과 감사 기록을 한곳에서 관리하면 사용자 식별 규칙을 더 일관되게 적용하고 온보딩 과정의 예외를 줄일 수 있습니다.

안전한 사용자 매핑을 기반으로 고객사 SSO를 확장하려면 AxiPass를 무료로 시작해 보세요.