OAuth 권한이 너무 넓지 않나요? B2B SaaS 스코프 최소화 가이드
OAuth·OIDC 앱의 스코프를 최소 권한으로 설계하고 고객사별 승인, 변경 기록, 정기 검토까지 운영하는 방법을 소개합니다.
B2B SaaS에 SSO를 붙일 때 로그인 성공만 확인하고 OAuth 스코프(scope)는 넓게 열어 두기 쉽습니다. 그러나 스코프는 앱이 사용자를 대신해 무엇을 읽고 변경할 수 있는지 정하는 권한 경계입니다. 토큰이 탈취되거나 연동 앱이 오작동하면 허용된 스코프만큼 영향 범위도 커집니다. 최근 IAM이 로그인 통제에서 지속적인 권한 관리로 확장되는 이유도 발급된 접근 권한을 계속 설명하고 줄여야 하기 때문입니다.
스코프를 최소화한다는 것은 무조건 개수를 줄이는 일이 아닙니다. 기능에 필요한 권한을 업무 단위로 나누고, 고객사 관리자가 이해할 수 있게 표시하며, 변경과 회수 절차를 갖추는 일입니다.
스코프를 기능 계약으로 설계하세요
큰 권한 하나보다 읽기와 쓰기를 분리합니다
admin이나 all 같은 포괄 권한은 구현은 빠르지만 위험과 승인 이유를 설명하기 어렵습니다. 예를 들어 사용자 조회, 그룹 조회, 사용자 변경, 감사 기록 열람을 별도 스코프로 나누면 읽기 전용 연동에 쓰기 권한이 따라가지 않습니다.
각 스코프에는 이름뿐 아니라 허용 작업, 대상 데이터, 필요한 제품 기능을 문서화하세요. OIDC의 openid, profile, email처럼 인증에 필요한 범위와 업무 API 접근 범위도 구분해야 합니다. 인증과 권한의 차이는 SSO 인증과 권한 부여에서 확인할 수 있습니다.
사용자 동의와 관리자 승인을 구분합니다
개인 프로필 조회와 조직 전체 사용자 변경은 위험 수준이 다릅니다. 테넌트 전체 데이터나 관리 작업을 허용하는 스코프는 관리자만 승인하게 하고, 어느 앱이 왜 요청하는지 보여주세요. 그룹 기반 앱 접근 정책과 함께 적용하면 앱에 로그인할 수 있는 사람과 앱이 행사할 수 있는 API 권한을 서로 다른 통제로 관리할 수 있습니다. 자세한 기준은 그룹 기반 앱 접근 정책을 참고하세요.
발급 이후에도 권한을 다시 확인하세요
변경은 새 승인으로 취급합니다
기존 앱이 더 강한 스코프를 요청할 때 조용히 추가하면 최초 승인의 의미가 사라집니다. 추가 권한, 변경 사유, 영향을 받는 테넌트를 알리고 재승인을 받으세요. 사용하지 않는 기능을 제거했다면 관련 스코프와 토큰도 함께 축소하거나 다시 발급해야 합니다.
감사 로그에는 값이 아니라 사건을 남깁니다
승인자, 앱, 테넌트, 스코프 집합, 승인·거부·회수 시각을 기록하세요. 액세스 토큰이나 클라이언트 시크릿 원문은 로그에 남기지 않습니다. 분기별로 미사용 앱, 과도한 쓰기 권한, 소유자 없는 연동을 검토하고 실제 API 로그와 대조하면 문서상 권한과 사용 권한의 차이를 찾을 수 있습니다. 비인간 계정의 수명주기는 SaaS 비인간 아이덴티티 관리와 함께 점검하세요.
AxiPass로 고객사별 권한 경계를 정리하세요
AxiPass는 멀티 테넌트 B2B SaaS를 위한 IdP로 OIDC/OAuth2, SAML, SCIM, MFA, SWA와 감사 로그를 통합합니다. 고객사별 앱 등록과 그룹 접근 정책, 변경 기록을 한 관리 경계에 두면 “누가 로그인할 수 있는가”와 “앱이 무엇을 할 수 있는가”를 함께 검토하기 쉬워집니다. 최소 권한은 한 번의 설정이 아니라 승인, 관찰, 축소를 반복하는 운영 원칙입니다.