기업에서 사용하는 시스템이 늘어나면 사용자가 관리해야 하는 계정과 로그인도 함께 늘어난다. 그룹웨어, ERP, 인사시스템, 클라우드 서비스, 보안 솔루션마다 별도의 아이디와 비밀번호를 입력해야 한다면 사용자 불편뿐 아니라 비밀번호 관리와 계정 통제의 복잡성도 커진다.
이 문제를 줄이기 위해 사용하는 대표적인 인증 구조가 SSO(Single Sign-On)다. SSO를 적용하면 사용자가 한 번 인증한 결과를 여러 애플리케이션에서 신뢰할 수 있기 때문에 시스템을 이동할 때마다 자격 증명을 다시 입력할 필요가 줄어든다.
하지만 SSO를 단순히 '한 번 로그인하면 모든 시스템을 사용할 수 있는 기능'으로 이해하면 실제 구조를 놓치기 쉽다. 핵심은 여러 애플리케이션이 사용자의 비밀번호를 각각 확인하는 대신 중앙의 신원 제공자(IdP)가 수행한 인증 결과를 신뢰하도록 인증 체계를 구성하는 것이다.
목차
- SSO의 기본 개념
- 기업 SSO를 구성하는 주요 요소
- SSO 인증이 동작하는 과정
- SAML과 OpenID Connect의 차이
- SSO와 인증·권한관리의 관계
- SSO가 가져오는 장점과 보안 위험
- 기업에서 SSO를 구축할 때 확인할 사항
- 실무자 관점에서 본 SSO
- 결론
1. SSO의 기본 개념
SSO는 사용자가 하나의 인증 절차를 거친 뒤 여러 애플리케이션을 추가 로그인 없이 이용할 수 있도록 하는 인증 방식이다. 중요한 점은 여러 시스템이 동일한 비밀번호를 공유하는 구조가 아니라는 것이다.
일반적인 SSO 환경에서는 애플리케이션이 직접 사용자의 비밀번호를 검증하지 않는다. 사용자를 중앙의 Identity Provider, 즉 IdP로 보내 인증하도록 하고, IdP가 전달한 인증 결과를 검증한 뒤 자체 로그인 세션을 생성한다.
예를 들어 한 직원이 그룹웨어에서 인증을 완료한 뒤 ERP를 실행했다고 가정해 보자. ERP가 동일한 IdP와 연동되어 있고 IdP의 인증 세션이 아직 유효하다면 IdP는 사용자의 비밀번호를 다시 입력받지 않고 기존 인증 상태를 이용해 ERP에 인증 결과를 전달할 수 있다. 이 과정이 사용자에게는 '한 번 로그인한 뒤 여러 시스템을 바로 사용하는 경험'으로 나타난다.
NIST의 디지털 신원 가이드라인에서도 이러한 구조를 연합 신원(Federation) 관점에서 설명한다. IdP가 사용자를 인증하고 검증 가능한 Assertion을 Relying Party에 전달하면, Relying Party는 이를 검증한 뒤 사용자 세션을 생성할 수 있다.
2. 기업 SSO를 구성하는 주요 요소
SSO 환경을 이해하려면 사용자와 애플리케이션만 보는 것이 아니라 인증 시스템 전체를 살펴봐야 한다.
| 구성 요소 | 역할 |
|---|---|
| 사용자 | 업무 시스템에 접근하려는 주체 |
| Identity Provider(IdP) | 사용자의 신원을 확인하고 인증 결과를 제공 |
| 사용자 디렉터리 | 사용자 계정, 조직 및 일부 속성 정보를 관리 |
| 인증 수단 | 비밀번호, MFA, 패스키 등 사용자를 검증하는 수단 |
| SP 또는 RP | IdP의 인증 결과를 신뢰하는 애플리케이션 |
| Assertion 또는 ID Token | 인증 결과와 사용자 식별 정보를 전달 |
| 애플리케이션 세션 | 인증 완료 후 각 애플리케이션이 생성하는 로그인 상태 |
Identity Provider
SSO 구조의 중심에는 IdP(Identity Provider)가 있다. 사용자가 어떤 사람인지 인증하고, 필요한 인증 정책을 수행한 뒤 그 결과를 애플리케이션에 전달한다. 기업 환경에서는 MFA, 인증 정책, 기기 상태 확인과 같은 추가 통제가 IdP와 결합되는 경우도 많다.
따라서 SSO가 여러 시스템에 적용될수록 IdP는 단순한 로그인 서버가 아니라 기업 인증 체계의 핵심 인프라가 된다.
Service Provider와 Relying Party
IdP가 제공하는 인증 결과를 받아 서비스를 제공하는 시스템을 SAML에서는 일반적으로 SP(Service Provider)라고 한다. OpenID Connect에서는 이에 해당하는 애플리케이션을 RP(Relying Party)라고 부른다.
명칭에는 차이가 있지만 중앙 인증 시스템이 확인한 사용자 신원을 애플리케이션이 신뢰한다는 기본 원리는 비슷하다. OASIS의 SAML 구조에서도 SSO를 위해 IdP와 SP의 역할을 정의하며, OpenID Connect에서는 인증 서버가 제공한 인증 결과를 RP가 검증하도록 정의한다.
3. SSO 인증이 동작하는 과정
SSO의 핵심은 사용자가 애플리케이션에 비밀번호를 직접 제출하는 대신 IdP가 인증을 담당하고 그 결과를 전달하는 것이다.
1단계. 사용자가 애플리케이션에 접근한다
사용자가 ERP나 그룹웨어 같은 업무 시스템을 실행한다. 애플리케이션은 자체적으로 로그인 정보를 확인하기보다 사용자가 이미 인증된 상태인지 확인한다.
2단계. 애플리케이션이 사용자를 IdP로 이동시킨다
인증된 세션이 없다면 애플리케이션은 사용자의 브라우저를 IdP의 인증 엔드포인트로 이동시킨다. 이 단계에서 애플리케이션은 자신이 어떤 서비스인지와 인증 후 사용자가 돌아올 위치 등의 정보를 IdP에 전달한다.
3단계. IdP가 사용자를 인증한다
IdP는 사용자의 인증 상태를 확인한다. 기존 IdP 세션이 없다면 비밀번호, MFA, 패스키 등 기업이 정한 인증 방식으로 사용자를 확인한다. 반대로 사용자가 조금 전에 다른 시스템을 사용하면서 이미 IdP 인증을 완료했고 해당 세션이 아직 유효하다면 다시 인증 정보를 요구하지 않을 수 있다.
바로 이 IdP 인증 세션의 재사용이 SSO 사용자 경험을 만드는 중요한 요소다.
4단계. IdP가 인증 결과를 전달한다
인증이 완료되면 IdP는 애플리케이션에 신뢰할 수 있는 인증 결과를 전달한다. SAML에서는 일반적으로 SAML Assertion이 사용되고, OpenID Connect에서는 ID Token이 사용된다. OpenID Connect의 ID Token은 인증 이벤트와 사용자에 관한 Claim을 포함하는 JWT 형식의 보안 토큰이다.
5단계. 애플리케이션이 인증 결과를 검증한다
애플리케이션은 받은 정보를 무조건 신뢰해서는 안 된다. 프로토콜에 따라 서명, 발급자, 대상 애플리케이션, 유효기간 등의 값을 검증해야 한다. OIDC에서는 ID Token의 issuer, audience, 만료시간 등 관련 Claim 검증이 중요하며, SAML 환경에서도 서명 인증서, issuer, audience와 필요한 Claim을 올바르게 검증해야 한다.
6단계. 애플리케이션이 자체 세션을 만든다
검증에 성공하면 애플리케이션은 사용자를 로그인된 사용자로 처리하고 자체 세션을 만든다. 여기서 중요한 점은 IdP의 로그인 세션과 각 애플리케이션의 세션이 완전히 동일한 것은 아니라는 것이다.
따라서 한 애플리케이션에서 로그아웃했다고 해서 모든 애플리케이션과 IdP에서 항상 동시에 로그아웃되는 것은 아니다. 전체 로그아웃 동작은 사용하는 프로토콜과 시스템별 구현 및 설정에 따라 달라질 수 있다.
7단계. 다른 애플리케이션에 접근한다
사용자가 다른 SSO 연동 시스템에 접속하면 해당 시스템 역시 IdP로 인증을 요청한다. IdP에 기존 인증 세션이 남아 있다면 다시 비밀번호를 입력하지 않고 인증 결과를 발급할 수 있다. 이 과정을 반복하면서 사용자는 여러 업무 시스템을 하나의 로그인 환경처럼 사용할 수 있다.
4. SAML과 OpenID Connect의 차이
기업 SSO에서 가장 많이 접하는 연동 방식으로 SAML 2.0과 OpenID Connect(OIDC)가 있다. 두 기술 모두 중앙에서 확인한 사용자 신원을 애플리케이션에 전달할 수 있지만 구조와 메시지 형식에는 차이가 있다.
| 구분 | SAML 2.0 | OpenID Connect |
|---|---|---|
| 기본 역할 | 인증 및 신원 연계 | 인증 및 신원 연계 |
| 기반 | SAML 표준 | OAuth 2.0 위에 구성된 Identity Layer |
| 주요 데이터 형식 | XML | JSON / JWT |
| 인증 결과 | SAML Assertion | ID Token |
| 주요 용어 | IdP / SP | OP / RP |
| 대표 적용 영역 | 기업 웹·SaaS, 기존 엔터프라이즈 환경 | 현대적 웹·모바일·클라우드 애플리케이션 |
| API 연계 | 상대적으로 중심 기능이 아님 | OAuth 2.0과 함께 활용하기 용이 |
SAML
SAML은 기업용 웹 애플리케이션과 SaaS 서비스에서 오랫동안 사용되어 온 연합 인증 표준이다. IdP가 사용자를 인증하면 XML 기반의 Assertion을 만들어 SP에 전달한다. SP는 Assertion의 서명과 사용자 정보를 검증한 뒤 로그인 세션을 생성한다.
기존 기업 시스템이나 상용 SaaS와의 SSO 연동에서는 현재도 쉽게 접할 수 있는 방식이다.
OpenID Connect
OIDC는 OAuth 2.0 위에 사용자 인증을 위한 Identity Layer를 추가한 프로토콜이다. OIDC에서 핵심적인 인증 정보는 ID Token이며, 일반적으로 JWT 형식으로 전달된다. 이를 통해 RP는 사용자가 어떤 사용자이며 어떤 인증 과정을 거쳤는지 확인할 수 있다.
여기서 주의할 부분이 있다. OAuth 2.0과 OIDC는 같은 개념이 아니다. OAuth 2.0은 기본적으로 리소스에 대한 권한 위임을 위한 프레임워크이고, OIDC가 그 위에 사용자 인증에 필요한 기능을 추가한다. 따라서 OAuth Access Token과 OIDC ID Token 역시 목적을 구분해서 사용해야 한다.
5. SSO와 인증·권한관리의 관계
SSO를 구축했다고 해서 모든 시스템의 접근권한까지 자동으로 동일해지는 것은 아니다. 인증(Authentication)은 사용자가 누구인지 확인하는 과정이고, 인가 또는 권한관리(Authorization)는 확인된 사용자가 어떤 기능과 데이터에 접근할 수 있는지를 결정하는 과정이다.
예를 들어 IdP를 통해 '홍길동이라는 직원이 정상적으로 인증되었다'는 사실을 ERP가 확인했다고 하더라도 ERP에서 재무 데이터를 조회할 수 있는지는 별도의 권한 정책에 따라 결정해야 한다.
IdP가 조직, 직무, 그룹 등의 정보를 Claim이나 Attribute로 제공하고 이를 접근제어에 활용할 수도 있지만 최종 권한 판단은 애플리케이션의 권한관리 체계와 함께 설계해야 한다.
따라서 기업 인증 구조에서는 보통 다음 영역을 구분해서 보는 것이 좋다.
- IAM: 사용자 계정과 접근권한을 전반적으로 관리
- SSO: 여러 시스템의 인증 경험을 통합
- MFA: 인증 단계의 신뢰 수준을 강화
- 애플리케이션 권한관리: 시스템 내부의 실제 접근 범위를 통제
SSO는 IAM 전체를 대체하는 기술이라기보다 기업 IAM 체계 안에서 인증을 통합하는 중요한 기능으로 보는 것이 적절하다.
6. SSO가 가져오는 장점과 보안 위험
SSO의 가장 눈에 띄는 장점은 로그인 편의성이지만 기업 입장에서는 중앙 통제가 더 중요한 효과가 될 수 있다.
사용자 인증을 중앙에서 통제할 수 있다
각 시스템이 독립적으로 비밀번호 정책과 인증 기능을 운영하면 보안 수준이 제각각이 되기 쉽다. SSO를 적용하면 사용자 인증을 IdP에 집중시키고 MFA나 인증 정책을 중앙에서 운영할 수 있다.
반복적인 비밀번호 입력을 줄일 수 있다
사용자가 여러 서비스의 비밀번호를 각각 기억하거나 반복 입력할 필요가 줄어든다. 애플리케이션 역시 연합 인증을 지원하는 경우 사용자 비밀번호를 직접 다루지 않고 IdP가 제공하는 인증 결과를 이용할 수 있다.
계정 차단의 일관성을 높일 수 있다
사용자의 계정 상태와 인증 정책을 중앙에서 관리하면 퇴직자나 접근이 제한된 사용자에 대한 인증을 한곳에서 통제하기가 쉬워진다. 다만 이것만으로 모든 애플리케이션 내부 계정과 기존 세션이 자동으로 제거된다는 의미는 아니다. 계정 프로비저닝과 디프로비저닝, 세션 만료까지 함께 관리해야 한다.
중앙 인증 시스템의 중요도가 높아진다
SSO의 장점은 동시에 위험 요소가 될 수 있다. 여러 시스템이 동일한 IdP를 신뢰하게 되면 IdP의 장애나 보안 사고가 여러 애플리케이션에 영향을 줄 수 있다. NIST SP 800-63C-4도 연합 인증 환경에서는 IdP에 대한 공격의 영향이 해당 IdP를 신뢰하는 RP로 전파될 수 있음을 설명한다.
따라서 SSO 도입은 단순히 로그인 화면을 하나로 통합하는 프로젝트가 아니라 중앙 인증 인프라를 핵심 보안 시스템으로 관리하는 작업에 가깝다.
7. 기업에서 SSO를 구축할 때 확인할 사항
SSO를 안정적으로 운영하려면 프로토콜 연동뿐 아니라 계정, 정책, 세션, 로그까지 함께 고려해야 한다.
애플리케이션별 인증 방식을 먼저 조사한다
기업에는 최신 SaaS뿐 아니라 오래된 내부 시스템도 존재한다. 각 시스템이 SAML, OIDC 또는 다른 인증 방식을 지원하는지 먼저 파악해야 한다. 모든 시스템을 동일한 방식으로 연동할 수 있다고 가정하면 구축 과정에서 예외가 계속 발생할 수 있다.
IdP 관리자 계정을 강하게 보호한다
SSO가 확대될수록 IdP의 관리자 권한은 많은 시스템의 인증 체계에 영향을 미칠 수 있다. 관리자 계정에는 강한 인증수단을 적용하고, 불필요한 관리자 권한을 제한하며, 설정 변경과 로그인 이벤트를 별도로 모니터링할 필요가 있다.
Assertion과 Token 검증을 정확하게 구현한다
SSO 연동은 '토큰을 받았다'는 사실만으로 끝나지 않는다. 발급자와 대상, 서명, 만료 여부 등을 정확히 검증해야 하며 OIDC의 redirect URI나 SAML의 Assertion Consumer Service와 같은 연동 설정도 의도한 값으로 제한해야 한다.
MFA와 함께 설계한다
SSO는 로그인 횟수를 줄여 주지만 그 자체가 강한 인증수단을 의미하지는 않는다. 따라서 중요한 기업 시스템에서는 SSO를 MFA와 함께 구성하고 시스템 위험도에 따라 추가 인증이나 인증 정책을 적용하는 구조가 필요하다.
계정 생명주기와 연결한다
직원이 입사하거나 부서를 이동하거나 퇴직했을 때 인증과 권한 상태가 함께 변경되어야 한다. SSO만 도입하고 각 애플리케이션에 오래된 계정과 권한이 남아 있다면 인증 통합의 효과가 제한된다.
세션 정책까지 설계한다
인증 성공 이후에는 IdP 세션과 애플리케이션별 세션이 존재할 수 있다. 따라서 로그인 유지시간, 재인증 조건, 중요 업무 수행 시 추가 인증, 사용자 비활성화 이후 기존 세션 처리 방식 등을 함께 검토해야 한다.
8. SSO에서 잘못 이해하기 쉬운 부분
SSO는 여러 시스템에서 같은 비밀번호를 사용하는 기능이다
그렇지 않다. 연합 SSO 구조에서는 애플리케이션이 사용자의 비밀번호를 직접 공유하는 것이 아니라 IdP의 인증 결과를 신뢰한다.
SSO를 도입하면 모든 시스템의 권한도 통합된다
SSO는 주로 인증을 통합한다. 애플리케이션 내부에서 어떤 메뉴와 데이터에 접근할 수 있는지는 별도의 권한체계가 필요하다.
SSO를 사용하면 비밀번호가 필요 없다
SSO와 Passwordless Authentication은 별개의 개념이다. SSO 환경에서도 IdP 인증수단으로 비밀번호를 사용할 수 있고, MFA나 패스키 같은 다른 인증수단을 함께 적용할 수도 있다.
SSO를 구축하면 보안이 자동으로 강화된다
중앙에서 인증정책을 관리하기 쉬워지는 장점은 있지만 IdP의 중요성도 함께 증가한다. IdP 계정 탈취, 관리자 권한 오남용, 잘못된 SAML/OIDC 설정, 장시간 유지되는 세션 등을 제대로 관리하지 않으면 오히려 사고 영향 범위가 커질 수 있다.
9. 실무자 관점에서 본 SSO
기업에서 SSO를 검토할 때 흔히 로그인 편의성이나 제품 기능에 먼저 관심을 둔다. 하지만 운영 관점에서 더 중요한 것은 어디에서 사용자를 인증하고, 어느 시스템이 그 인증 결과를 신뢰하며, 계정이 변경되거나 차단됐을 때 어디까지 영향을 미치는지를 명확히 파악하는 것이다.
특히 SSO가 확대될수록 IdP는 기업 내 여러 시스템으로 접근하기 위한 관문이 된다. 그만큼 IdP의 관리자 계정, 인증 정책, 설정 변경 이력, 인증 로그에 대한 통제 수준도 높아져야 한다.
또 하나의 문제는 레거시 시스템이다. 최신 클라우드 서비스는 SAML이나 OIDC를 지원하는 경우가 많지만 오래된 내부 애플리케이션은 독자적인 계정체계를 사용하는 경우가 있다. 이 때문에 실제 기업 환경에서는 모든 시스템을 한 번에 SSO로 전환하기보다 애플리케이션을 분류하고 지원 가능한 인증 방식을 기준으로 단계적으로 전환하는 접근이 현실적이다.
결국 SSO 프로젝트의 완성도는 로그인 화면이 얼마나 잘 통합됐는지가 아니라 인증, 계정 생명주기, 권한, 세션, 로그가 하나의 운영체계로 연결되어 있는지에 의해 결정된다.
10. 결론
SSO는 한 번 로그인하는 편리한 기능을 넘어 기업 인증체계를 중앙화하는 중요한 기술이다. 사용자가 애플리케이션에 접근하면 중앙 IdP가 사용자를 인증하고 SAML Assertion이나 OIDC ID Token과 같은 인증 정보를 전달한다. 애플리케이션은 이를 검증한 뒤 자체 로그인 세션을 생성하며, IdP에 이미 유효한 인증 세션이 존재할 경우 사용자는 다른 시스템에서도 자격 증명을 반복해서 입력하지 않을 수 있다.
이 구조를 통해 사용자 편의성과 중앙 인증정책 적용 능력을 높일 수 있지만 동시에 IdP가 여러 시스템의 핵심 신뢰 지점이 된다는 점을 고려해야 한다.
따라서 기업에서 SSO를 도입할 때는 프로토콜 연동만 볼 것이 아니라 IdP 보호, MFA, 계정 생명주기, Assertion·Token 검증, 권한관리, 세션 정책, 로그 모니터링을 함께 설계해야 한다.
SSO는 여러 로그인 화면을 하나로 줄이는 기능이 아니라 기업 전체에서 '누구의 인증 결과를 어떤 시스템이 신뢰할 것인가'를 설계하는 인증 아키텍처라고 보는 것이 더 정확하다.