SSO 로그인만으로 충분할까? 인증과 권한 부여의 차이
SSO 인증 이후에도 과도한 앱 접근이 남는 이유와 OIDC·SAML, 그룹 정책, SCIM을 연결해 최소 권한을 운영하는 방법을 설명합니다.
SSO를 도입하면 사용자는 한 번 로그인해 여러 업무 앱에 접근할 수 있습니다. 그러나 “누구인지 확인했다”와 “무엇을 해도 되는지 결정했다”는 서로 다른 문제입니다. 현관에서 신분증을 확인했다고 건물의 모든 방 열쇠를 건네지 않는 것과 같습니다.
최근 아이덴티티 보안에서는 로그인 자체뿐 아니라 인증 이후의 과도한 권한과 접근 통제가 중요하게 다뤄집니다. SSO를 보안의 종착점이 아니라 권한 관리의 출발점으로 봐야 하는 이유입니다. SSO의 기본 구조는 SSO란 무엇인가에서 먼저 확인할 수 있습니다.
인증과 권한 부여는 어떻게 다를까요?
인증은 “누구인가”를 확인합니다
인증(Authentication)은 비밀번호, MFA, 회사 도메인 같은 신호로 사용자의 신원을 확인합니다. IdP는 확인 결과를 OIDC 토큰이나 SAML 어설션으로 서비스에 전달합니다. 여기에는 사용자 식별자와 이메일, 그룹 같은 정보가 포함될 수 있습니다.
권한 부여는 “무엇을 할 수 있는가”를 정합니다
권한 부여(Authorization)는 확인된 사용자가 어떤 앱에 들어가고 어떤 기능을 실행할 수 있는지 결정합니다. 같은 회사 구성원이라도 개발자는 소스 저장소, 재무 담당자는 결제 시스템에 접근해야 합니다. 모든 인증 사용자에게 모든 앱을 열어 두면 SSO는 편리한 단일 출입구일 뿐 최소 권한을 보장하지 못합니다.
SSO 이후의 접근을 설계하는 네 단계
1. 앱별 허용 대상을 그룹으로 정의합니다
개인별 예외를 쌓기보다 직무와 책임에 맞춘 그룹을 만들고 앱 접근 정책에 연결하세요. 인사 이동 때 그룹만 변경하면 여러 앱의 권한을 일관되게 조정할 수 있습니다. 구체적인 운영 방법은 그룹 기반 앱 접근 정책을 참고하세요.
2. 전달할 속성을 최소화합니다
OIDC 클레임이나 SAML 속성에는 서비스가 실제로 필요한 정보만 포함합니다. 편의를 이유로 조직·직급·개인정보를 모두 넘기면 노출 범위가 넓어집니다. 속성 이름과 값의 기준도 테넌트별로 문서화해야 합니다.
3. 입사·이동·퇴사를 하나의 수명주기로 연결합니다
SCIM은 계정 생성과 비활성화를 자동화하는 데 유용하지만, 기준이 되는 그룹과 상태가 부정확하면 잘못된 접근도 빠르게 전파될 수 있습니다. 인사 변경, 그룹 정책, 앱 계정 상태를 함께 검토하고 퇴사 시 SSO 차단과 앱 계정 비활성화가 모두 완료됐는지 확인하세요. SCIM 퇴사자 계정 자동화에서 체크포인트를 볼 수 있습니다.
4. 예외와 변경을 기록합니다
임시 권한에는 만료 시각과 승인자를 두고, 그룹 변경·앱 접근·정책 수정은 감사 로그로 남깁니다. 정기 검토에서는 “로그인했는가”보다 “현재도 이 앱이 필요한가”를 질문해야 합니다.
비SSO 앱도 같은 원칙으로 관리하세요
OIDC나 SAML을 지원하지 않는 앱을 SWA로 연결하더라도 접근 대상, 계정 배정, 회수 기준은 동일해야 합니다. 프로토콜별 화면을 따로 운영하기보다 SSO 앱과 비SSO 앱을 한 목록에서 관리해야 사각지대를 줄일 수 있습니다.
AxiPass로 인증과 앱 접근을 연결하세요
AxiPass는 SaaS 기업용 멀티 테넌트 IdP로 OIDC·SAML SSO, SCIM, MFA, SWA, 그룹 기반 앱 정책과 감사 로그를 통합합니다. 고객사별 테넌트를 분리하면서 로그인부터 계정 수명주기, 앱 접근 변경까지 한 흐름으로 관리해 보세요.