2025년 11월 16일·6분
SSO를 위한 OAuth vs SAML: 기업 구매자가 기대하는 것
SSO를 위한 OAuth와 SAML을 이해하기 쉽게 설명하고, 기업이 묻는 것, 무엇을 구축해야 하는지, 기존 로그인을 유지하는 방법을 정리합니다.
SSO를 위한 OAuth와 SAML을 이해하기 쉽게 설명하고, 기업이 묻는 것, 무엇을 구축해야 하는지, 기존 로그인을 유지하는 방법을 정리합니다.
SSO는 거래가 "팀 평가" 단계에서 회사 전사 배포로 넘어가는 순간 긴급해집니다. 구매 담당자는 제품을 좋아할 수 있지만, 보안과 IT는 직원들이 새 비밀번호를 만들어야 하거나, 또 다른 장소에서 MFA를 관리해야 하거나, 역할 변경 시 계정을 잃게 되는 상황이면 구매를 지연시킵니다.
많은 엔터프라이즈에게 SSO는 편의성보다 통제에 관한 문제입니다. 한 곳에서 로그인 규칙을 적용하고 접근을 빠르게 취소하며, 감사 대응을 위해 아이덴티티가 중앙에서 관리된다는 것을 보여주고 싶어합니다. 그래서 영업 사이클 후반부에 "OAuth vs SAML for SSO"라는 질문이 나옵니다. 이는 그들이 가진 아이덴티티 환경에 귀사가 맞는지를 빠르게 확인하는 방법입니다.
SSO를 나중에 추가하면 이미 의존하고 있던 가정을 깨뜨릴 수 있습니다. 현재 모델이 "one email = one user"라면, SSO는 공유 별칭, 여러 IdP, 마이그레이션 동안 비밀번호 로그인과 SSO를 병행해야 하는 사용자 같은 엣지 케이스를 도입합니다. 계정 연결이 잘못되면 사람들은 접근을 잃거나 더 나쁘게는 잘못된 테넌트에 접근 권한을 얻게 됩니다.
SSO는 온보딩과 지원 방식도 바꿉니다. 잘하면 비밀번호 재설정과 "이 계정은 누가 관리하나요?" 같은 티켓이 줄어듭니다. 못하면 롤아웃이 지연되고 관리자 불만이 커지며, 제품이 "평가판에선 작동했지만" 배포 첫날에 실패해 갱신이 위험해질 수 있습니다.
의사결정은 보통 한 사람의 몫이 아닙니다. 구매 담당자는 추진력을 원하고, 보안 담당자는 리스크와 감사 요건을 확인하며, IT 관리자는 명확한 설정 단계를 필요로 하고, 최종 사용자는 매끄러운 로그인을 원합니다. 지원팀은 결국 잠김, 마이그레이션, 예외 처리를 담당하게 됩니다.
Koder.ai 같은 플랫폼 위에서 앱을 빌드한다면 고객이 이미 활성화된 뒤에 아이덴티티를 재설계하는 일이 없도록 초기부터 SSO를 계획하는 것이 도움이 됩니다.
**SSO (single sign-on)**은 고객이 귀사 앱에 별도의 비밀번호를 만들어 로그인하는 대신 회사 로그인으로 앱에 접근하는 것을 의미합니다. 그들은 회사 계정으로 로그인하고 접근은 회사 정책으로 통제됩니다.
다음은 엔터프라이즈 콜에서 자주 듣는 용어입니다:
사람들이 "OAuth 로그인"이라고 말할 때, 종종 **OpenID Connect (OIDC)**를 의미합니다. OAuth는 주로 권한 부여(무언가에 접근할 권한)를 위한 것입니다. OIDC는 인증(사용자가 누구인지)을 추가해 로그인에 사용할 수 있게 합니다.
SAML은 오래된 XML 기반의 SSO 표준입니다. 엔터프라이즈에서는 여전히 널리 사용되는데, 입증된 규격이고 많은 IdP가 지원하며 컴플라이언스 체크리스트에 자주 포함되어 있기 때문입니다.
SCIM은 SSO가 아닙니다. SCIM은 프로비저닝용입니다: 사용자(때로는 그룹)를 자동으로 생성, 업데이트, 비활성화하는 것. 일반적인 구성은 SAML 또는 OIDC로 로그인하고, SCIM으로 접근을 수동으로 관리하지 않도록 하는 방식입니다.
엔터프라이즈 바이어는 보통 프로토콜 세부사항으로 시작하지 않습니다. 그들은 리스크와 통제부터 시작합니다: "우리 IdP에서 접근을 관리할 수 있나, 누가 무엇을 했는지 증명할 수 있나?"
대부분의 엔터프라이즈 팀은 최소한 하나의 엔터프라이즈 친화적 옵션을 원하고, 많은 경우 둘 다를 원합니다:
그들은 또한 설정 방식에 대해 묻습니다: 메타데이터 또는 디스커버리 URL, 인증서 회전, IT가 엔지니어 대기 없이 스스로 설정할 수 있는지 등.
엔터프라이즈 딜을 잃는 가장 빠른 방법은 오프보딩에 대해 모호한 태도를 보이는 것입니다. 직원이 떠나거나 부서를 옮기거나 노트북을 분실했을 때 무슨 일이 일어나는지 묻습니다.
예상되는 질문들:
그들이 신경 쓰는 간단한 시나리오: 관리자가 9:02에 사용자를 비활성화했을 때 9:03에는 그 사용자가 브라우저 탭을 열어도 앱을 열 수 없어야 합니다. 그 흐름을 명확히 설명하지 못하면 검토 주기가 길어질 것입니다.
OAuth는 원래 비밀번호를 공유하지 않고 한 시스템이 다른 시스템의 API를 호출할 수 있게 하기 위해 만들어졌습니다. 많은 팀이 여전히 통합(예: 캘린더를 읽는 통합)에 이를 사용합니다. 직원 로그인에는 대부분 OpenID Connect(OIDC)를 사용합니다. OIDC는 OAuth 위에 표준화된 로그인 인증 방식을 추가합니다.
OIDC의 일반적 설정은 authorization code flow입니다. 귀사 앱은 사용자를 회사의 IdP로 보냅니다. 로그인에 성공하면 IdP는 짧은 수명(authorization code)을 귀사 앱으로 반환합니다. 백엔드가 그 코드를 토큰으로 교환합니다.
중요한 토큰 구분:
OAuth와 SAML을 비교하는 현실적인 판단: 웹, 모바일, API 패턴에 잘 맞는 현대적 로그인을 원하면 OIDC가 좋습니다. 엔터프라이즈가 고전적인 "앱에 로그인" 핸드셰이크를 원하고 API 접근에는 덜 관심이 있으면 SAML이 더 흔합니다.
저장해야 할 것은 단순하게 유지하세요: 사용자의 안정적인 식별자(subject), 제공된 경우 이메일, 그리고 사용자가 사용한 테넌트 연결. 사용자의 비밀번호는 저장하지 마세요. 오프라인 API 접근이 정말 필요하지 않다면 장기 유효한 리프레시 토큰도 피하세요.
테넌트별로 작동하려면 다음이 필요합니다:
잘하면 사용자는 앱으로 돌아오고, 토큰을 검증해 평소 세션을 생성할 수 있으며 전체 인증 모델을 다시 쓰지 않아도 됩니다.
SAML은 엔터프라이즈 IdP가 귀사 앱에 "이 사람은 이미 로그인했습니다, 여기 정보가 있습니다"라고 알리는 방식입니다. IdP는 SAML 어설션을 전송하는데, 이는 서명된 짧은 유효 기간의 메시지로 사용자가 누구인지(때로는 그룹/역할 정보도 포함)를 담고 있습니다.
그 메시지를 신뢰할 수 있게 만들기 위해 SAML은 메타데이터와 인증서에 의존합니다. 메타데이터는 엔드포인트와 키를 설명하는 작은 구성 패키지입니다. 인증서는 주로 서명에 사용되어 귀사 앱이 어설션이 고객 IdP에서 왔고 변경되지 않았음을 확인할 수 있게 합니다.
거의 모든 설정에서 두 가지 식별자가 등장합니다:
둘 중 하나라도 틀리면 다른 것이 올바르더라도 로그인이 실패합니다.
현실의 SAML은 코드만큼 운영이 중요합니다. 테넌트 수준의 SAML 설정, 다운타임 없는 인증서 회전, 시계 차이(clock skew) 처리(몇 분 차이로도 어설션이 깨질 수 있음), 관리자에게 친절한 오류 메시지(단순히 "invalid response"가 아닌)를 계획하세요.
일반적인 패턴은 다음과 같습니다: 고객 관리자가 테넌트별로 SAML을 활성화하면, 귀사 앱은 서명을 검증하고 어설션이 만료되지 않았는지 확인한 뒤 이메일(또는 NameID)을 기존 사용자에 매핑하거나 안전한 자동 프로비전 규칙을 적용합니다. 실제로 이것이 OAuth vs SAML 결정의 핵심입니다: SAML은 보통 더 강력한 관리자 워크플로를 구축하도록 요구합니다.
OIDC와 SAML 사이의 선택은 대부분 구매자가 이미 무엇을 운영 중인지에 달려 있습니다. 많은 B2B 앱은 시간이 지나면서 둘 다 지원하게 되지만, 고객별로는 깔끔한 결정을 내리고 인증 시스템을 예측 가능하게 유지할 수 있습니다.
OIDC는 현대적 앱에 더 원활한 경우가 많습니다. 브라우저와 모바일 앱에 잘 맞고, API와도 잘 어울리며 확장과 디버깅이 비교적 쉬운 편입니다(스코프, 토큰 수명 등). 엔터프라이즈 고객이 이미 현대적인 IdP 설정을 사용하고 IT팀이 OIDC에 익숙하다면 우선 OIDC를 고려하세요.
반면 SAML은 협상이 불가능한 경우가 있습니다. 많은 대기업은 기존 SAML 프로그램과 공급업체 온보딩 규칙(예: "벤더는 SAML만")을 가지고 있습니다. 이런 경우 최선의 접근법은 한 번 통제된 방식으로 SAML을 구현하고 이를 로그인 시스템의 나머지와 격리하는 것입니다.
결정 전에 물어볼 질문들:
간단한 결정 가이드:
| 고객이 말하면... | 권장 | 이유 |
|---|---|---|
| "우리는 Entra ID를 사용하고 현대적 앱 통합을 원합니다" | OIDC | 웹과 API 흐름에 더 적합 |
| "우리 정책은 공급업체에 대해 SAML만 허용" | SAML | 보안 온보딩을 통과하려면 필수 |
| "다른 자회사에는 둘 다 필요" | 둘 다 | 대기업에서 흔함 |
| "앱별로 커스텀 클레임이 필요" | 둘 다 | 속성 매핑을 지원함 |
둘 다 지원한다면 앱의 나머지 부분은 일관되게 유지하세요: 하나의 내부 사용자 모델, 하나의 세션 모델, 하나의 권한 규칙 세트. SSO 방식은 "이 사용자가 누구이고 어느 테넌트에 속하는가"를 답해야지 접근 방식을 재정의하면 안 됩니다.
먼저 제품에서 "테넌트"가 무엇인지 정의하세요. 대부분의 B2B 앱에서 SSO는 사용자별이 아니라 조직 또는 워크스페이스별로 구성됩니다. 그 선택은 IdP 설정을 어디에 저장할지, 누가 변경할 수 있는지, 사용자가 워크스페이스 간에 어떻게 이동하는지를 결정합니다.
다음으로 예측 가능한 로그인 동작을 선택하세요. 이메일 도메인 라우팅(이메일을 입력하면 도메인이 SSO 활성화되어 있으면 리디렉션)은 혼란을 줄이지만, 계약자나 다중 도메인 회사 같은 엣지 케이스를 처리해야 합니다. "SSO로 계속하기" 버튼은 이해하기 쉽지만 사용자가 잘못된 옵션을 선택할 수 있습니다.
OIDC든 SAML이든 안전한 빌드 순서:
테스트는 선택이 아닙니다. 샌드박스 IdP와 현실적인 도메인을 가진 스테이징 테넌트를 사용하세요. 정상 흐름과 실패 케이스를 실행하세요: 만료된 인증서, 잘못된 audience, 시계 차이, IdP에서 사용자 제거 등. SSO 롤아웃을 기능 플래그처럼 취급하세요.
Koder.ai 같은 플랫폼은 테넌트별 구성과 스냅샷·롤백을 지원해 잘못된 변경이 모든 고객을 잠그지 않도록 반복 작업을 쉽게 합니다.
SSO는 단순한 로그인 버튼이 아닙니다. 보안 팀은 세션 길이, 오프보딩, 문제가 생겼을 때 증명할 수 있는 사항을 묻습니다. SSO를 인증 시스템의 핵심으로 취급하면 대부분의 고통스런 에스컬레이션을 피할 수 있습니다.
세션 규칙부터 시작하세요. 유휴 타임아웃과 절대 세션 수명을 정하고, 사용자가 노트북을 닫았다가 다음 날 돌아왔을 때 무슨 일이 일어나는지 명확히 하세요. OIDC에서는 리프레시 토큰이 세션을 예상보다 오래 유지할 수 있으므로(회전, 최대 수명) 제한을 설정하세요. SAML에서는 브라우저 세션이 오래 지속될 수 있으니 재인증을 강제할 조건을 설계하세요.
로그아웃도 함정입니다. "Single logout"은 보편적이지 않습니다. 앱 내부 로그아웃을 신뢰성 있게 지원하고, 전역 로그아웃은 IdP에 따라 달라질 수 있음을 문서화하세요.
MFA도 비슷합니다. 엔터프라이즈는 IdP가 MFA를 강제하기를 원하므로 귀사 앱은 추가 인증을 요구하지 않고 인증된 사용자를 받아들여야 합니다. 다만 데이터 내보내기나 결제 정보 변경 같은 위험한 작업에는 추가 인증(step-up)을 요구하는 것이 유용합니다.
사용자 프로비저닝은 접근 누수(access leak)가 발생하는 지점입니다. JIT 프로비저닝은 편리하지만 인증 가능한 누구에게나 계정을 생성할 수 있습니다. 초대 전용(invite-only)은 더 안전하지만 관리자 부담이 늘어납니다. 많은 팀은 중간 지점을 선택합니다: 도메인으로 제한하거나 그룹 클레임으로 제한한 상태에서 JIT를 허용합니다.
SSO 구성은 최소 권한 역할로 제한하세요. 인증서 회전이나 IdP URL 업데이트를 위해 슈퍼-관리자 권한이 필요하면 안 됩니다.
지원용으로는 비밀을 저장하지 않으면서 단일 로그인을 추적할 수 있는 충분한 로그를 남기세요:
이 차이가 "재현할 수 없다"는 답변과 수 분 만에 엔터프라이즈 SSO 장애를 해결하는 차이를 만듭니다.
중견 시장 회사가 조달 부서를 통과하면서 "서명 전에 SSO가 필요합니다"라고 말합니다. 이는 철학적 문제가 아니라 온보딩, 오프보딩, 감사에 필요한 통제 수단입니다.
여기서 트위스트: 귀사는 두 팀에 판매하고 있습니다. A팀은 Okta로 OIDC를 원하고, B팀은 레거시 도구 때문에 SAML을 고집합니다. 이때 OAuth vs SAML 논쟁은 더 이상 논쟁이 아니라 롤아웃 계획이 됩니다.
한 가지 규칙을 지키세요: SSO는 전역 대체가 아니라 테넌트별 로그인 옵션입니다. 기존 사용자는 테넌트 관리자가 "SSO 필수"로 전환할 때까지 기존 방식으로 로그인할 수 있어야 합니다.
첫 SSO 로그인 시 안전한 계정 연결이 필요합니다. 깔끔한 접근 방식은: 확인된 이메일로 매칭하고(또는 초대), 테넌트를 도메인으로 확인한 다음 IdP 아이덴티티를 기존 사용자에 연결하는 것입니다. 매치가 없으면 관리자가 허용한 경우에만 JIT로 사용자를 생성하세요.
역할 할당은 딜을 막는 지점입니다. 단순하게 유지하세요: 신규 사용자에 대한 기본 역할과 IdP 그룹 또는 클레임에서 귀사 역할로 매핑하는 선택적 매핑을 제공합니다.
관리자 측에서는 보통 다음을 구성해야 합니다:
전환 중 잠금 방지를 위해 SSO 외부의 브레이크글래스 관리자 계정을 유지하고, 처음 로그인 몇 번은 테스트 모드로 실행하며, 최소한 하나의 확인된 관리자 세션이 있을 때만 SSO를 강제하세요.
대부분의 SSO 사고는 IdP 때문에 발생하지 않습니다. 앱이 SSO를 전역 스위치로 취급하고 테넌트별로 관리하지 않을 때 발생합니다.
고전적 실패 사례는 테넌트 경계 누락입니다. 하나의 IdP 구성이 전역으로 저장되어 마지막에 수정한 IdP로 모든 고객이 리디렉션되는 경우가 있습니다. IdP 설정은 항상 테넌트에 묶고 SSO 핸드셰이크를 시작하기 전에 테넌트를 해결하세요.
계정 매칭도 큰 함정입니다. 이메일만 신뢰하면 중복 계정이 생성되거나 IdP에서 받은 이메일이 이전에 사용한 이메일과 다를 때 실제 사용자가 잠기는 문제가 생깁니다. 병합 정책을 사전에 정의하세요: 어떤 식별자를 신뢰할지, 이메일 변경을 어떻게 처리할지, 관리자가 엔지니어 도움 없이 불일치를 수정할 수 있는 방법을 정하세요.
팀은 또한 클레임을 과신하는 경향이 있습니다. 반환된 데이터를 검증하세요: issuer, audience, 서명, 이메일이 확인되었는지(또는 안정적인 subject 식별자를 사용) 등을 항상 확인하세요. 잘못된 audience를 수락하거나 확인되지 않은 이메일을 신뢰하면 잘못된 사람에게 접근 권한을 부여할 수 있습니다.
문제가 발생했을 때 모호한 오류는 긴 지원 통화를 초래합니다. 사용자에게는 명확한 메시지를 주고, 관리자에게는 진단 힌트(예: "Audience mismatch" 또는 "Certificate expired")를 제공하되 비밀은 노출하지 마세요.
시간 관련 문제는 배포 전에 테스트할 가치가 큽니다. 시계 차이와 인증서 회전은 월요일 아침 9시에 로그인을 깨트릴 수 있습니다.
대부분의 장애를 예방하는 다섯 가지 점검:
sub 또는 NameID)를 사용하고 안전한 병합 정책을 정의할 것SSO는 작은 가정이 큰 지원 티켓으로 이어지는 곳입니다. 엔터프라이즈 고객에게 지원한다고 말하기 전에 데모가 아니라 제품에서 기본이 제대로 작동하는지 확인하세요.
스테이징 환경에서 다음을 점검하세요:
하나의 완전한 "나쁜 날" 연습을 하세요: 인증서 회전, 클레임 변경, 또는 IdP URL 깨뜨리기를 실행해 이를 빠르게 감지하고 복구할 수 있는지 확인하세요.
그런 다음 테넌트별 SSO 실패에 대한 모니터링과 알림, 그리고 연습해본 롤백 계획(기능 플래그, 구성 되돌리기, 빠른 배포)을 갖추세요.
명확한 시작점을 선택하세요. 대부분의 엔터프라이즈 바이어는 "Okta/Entra ID와 SAML" 또는 "Google/Microsoft와 OIDC"를 요청하고, 초기에 둘 다를 약속하려면 팀이 준비되어 있어야 합니다. 무엇을 먼저 지원할지(SAML만, OIDC만, 또는 둘 다) 결정하고 제품과 지원팀에 대해 "완료"가 무엇인지 문서화하세요.
실제 고객을 참여시키기 전에 작은 내부 데모 테넌트를 만드세요. SSO 활성화, 로그인 테스트, 도메인 제한, 문제가 생겼을 때 복구 절차를 연습하세요. 이곳에서 지원 플레이북도 검증됩니다.
지원하는 내용이 시간이 지나며 바뀔 수 있으니 살아있는 엔터프라이즈 요구사항 문서를 유지하세요. 지원한다고 한 내용을 한곳에 기록해두면 나중에 온보딩을 망치는 일회성 약속을 피할 수 있습니다.
실제적으로 작동하는 간단한 계획:
제품 측면에서 빠르게 진행하려면 설정 화면과 테넌트 구조를 Koder.ai(koder.ai)에서 프로토타입하고 고객의 보안 질문이 들어올 때마다 반복하세요.
SSO 직후 자주 따라오는 추가 기능(예: SCIM 프로비저닝, 감사 로그 내보내기, 명확한 권한을 가진 관리자 역할)은 출시 직후 요구될 가능성이 높습니다. 즉시 모두 출시하지 않더라도, 바이어에게 일관된 답변을 할 수 있도록 준비해두세요.
대부분의 엔터프라이즈 팀은 접근 제어를 중앙에서 관리하기를 원합니다. SSO는 그들에게 MFA 및 로그인 규칙을 IdP에서 적용할 수 있게 하고, 직원이 퇴사했을 때 접근을 빠르게 제거할 수 있으며, 감사 요구사항을 충족시키는 방법을 제공합니다. 이는 비밀번호 관리를 귀사 앱에 의존하지 않아도 된다는 뜻입니다.
우선 해당 고객이 이미 어떤 IdP를 사용하는지와 공급사 온보딩 정책을 확인하세요. OIDC는 현대적인 웹/모바일 흐름에서 더 부드럽게 작동하는 경우가 많고, SAML은 많은 대기업에서 표준으로 요구되기 때문에 필수인 경우가 있습니다. 실제로는 고객의 기존 환경과 보안 요구가 결정 요인입니다.
OIDC는 로그인 용도로 설계된 OAuth 위의 인증 레이어입니다. OAuth 자체는 주로 API 접근 권한 위임을 위한 것이고, 사용자가 누구인지 증명하기 위해선 OIDC를 사용한다고 생각하면 됩니다. 즉, “회사 IdP로 로그인”을 구현하려면 대부분 OIDC를 의미합니다.
필수는 아닙니다. SSO는 사용자가 로그인하는 방법이고, SCIM은 사용자 계정을 자동으로 생성·갱신·비활성화하는 프로비저닝입니다. 일반적인 엔터프라이즈 구성은 SAML 또는 OIDC로 로그인하고, SCIM으로 오프보딩과 역할 변경을 자동화하는 방식입니다.
SSO 설정은 테넌트별로 관리해야 합니다. 도메인 라우팅, 초대(invite), 또는 명시적 조직 선택으로 먼저 테넌트를 결정한 다음 그 테넌트의 IdP 구성으로 SSO 핸드셰이크를 시작하세요. 이렇게 하면 한 고객의 IdP 설정이 다른 고객에 영향을 주는 것을 막을 수 있습니다.
IdP에서 받은 안정적인 식별자(예: OIDC의 sub 또는 SAML의 NameID)를 기본 연결 키로 사용하고, 이메일은 변경 가능한 보조 속성으로 취급하세요. 첫 SSO 로그인 시에는 동일 인물임을 확신할 수 있을 때만 기존 계정과 연결하고, 그렇지 않으면 초대나 관리자 확인을 요구하세요.
SSO가 적용되더라도 브레이크글래스 관리자 계정을 유지하세요. SSO는 옵트인 상태로 두고 관리자가 작동을 확인할 때까지 기존 로그인 방법을 허용하세요. 또한 테넌트별로 SSO를 비활성화할 수 있는 토글을 제공하면 IdP 설정이 잘못되어도 코드 배포 없이 복구할 수 있습니다.
앱 내부에서 로컬 로그아웃을 안정적으로 지원하고, 모든 애플리케이션에서의 전역 로그아웃은 고객의 IdP 기능과 설정에 달려 있음을 문서화하세요. 또한 접근 차단을 빠르게 적용하려면 세션 만료 정책이나 사용자 상태 재검사를 설계해 비활성화된 사용자가 오래된 브라우저 탭으로 계속 접근하지 못하게 하세요.
민감한 데이터를 노출하지 않으면서 문제를 추적할 수 있도록 테넌트 범위의 SSO 오류 로그를 남기세요. 캡처할 항목 예시는 다음과 같습니다:
원시 토큰, 전체 SAML 어설션, 클라이언트 시크릿 또는 개인 키는 로그에 저장하지 마세요.
먼저 테넌트 수준 구성 저장소를 만들고, IdP 설정을 관리할 관리자 UI, 안전한 계정 연결 규칙, 그리고 롤백 경로를 구현하세요. Koder.ai 위에서 빌드한다면 테넌트 모델을 일찍 설계하고 스냅샷·롤백을 활용해 롤아웃 중 문제가 생겨도 모든 고객이 잠기지 않도록 하세요.