SSO란 무엇인가요?

SSO는 사용자가 단일 인증 정보 세트로 한 번만 로그인하면, 사용 권한이 부여된 모든 애플리케이션과 서비스에 접근할 수 있게 해주는 인증 방식입니다. 사용자는 애플리케이션마다 별도의 비밀번호를 관리할 필요 없이, 신원 제공자(IDP)를 통해 한 번만 인증하면 되며, 이 인증 결과는 연결된 각 서비스에서 신뢰하게 됩니다.

비즈니스 환경에서 SSO는 일반적으로 내부 IT 또는 보안 팀이 관리하며, 조직의 ID 제공자와 연동됩니다. 이는 보다 광범위한 신원 및 접근 관리와 밀접한 관련이 있으며, 다단계 인증, 적응형 정책, 비밀번호 없는 인증과 같은 추가적인 제어 수단을 적용하기 위한 진입점 역할을 하는 경우가 많습니다.

SSO가 왜 업무 환경에서 필수 요소가 되었는지 더 자세히 알아보려면 다음을 참조하십시오. 단일 로그인(SSO): 지금 그 어느 때보다 필요합니다.

SSO는 인증을 처리하는 신원 제공자와 사용자가 접속하려는 애플리케이션 또는 시스템인 서비스 제공자를 연결하는 방식으로 작동합니다. 사용자가 로그인을 시도하면, 서비스 제공자는 인증 요청을 신원 제공자에게 전달합니다. 신원 제공자는 사용자를 검증하고, 인증을 확인하는 서명된 토큰을 발급한 뒤 이를 다시 전달합니다. 서비스 제공자는 해당 토큰을 신뢰하고 접근 권한을 부여합니다.

일반적인 SSO 로그인 절차는 다음과 같습니다:

1. 사용자가 비즈니스 애플리케이션(서비스 제공자)으로 이동합니다.
2. 이 애플리케이션은 인증을 위해 사용자를 신원 제공자로 리디렉션합니다.
3. ID 제공자는 사용자가 이미 로그인되어 있는지 확인합니다. 이미 로그인되어 있다면 다음 단계로 넘어갑니다. 그렇지 않은 경우, 비밀번호, 2단계 인증 또는 비밀번호 없는 인증 수단 등이 포함될 수 있는 인증 정보를 입력하라는 메시지를 표시합니다.
4. ID 제공자는 사용자를 인증하고 서명된 인증 토큰을 생성합니다.
5. 토큰은 서비스 제공자에게 다시 전달되며, 서비스 제공자는 설정 과정에서 구축된 신뢰 관계를 바탕으로 토큰의 유효성을 확인합니다.
6. 사용자는 자격 증명을 다시 입력하지 않고도 액세스 권한을 부여받습니다.

동일한 사용자가 다른 연결된 애플리케이션으로 이동하면, 해당 애플리케이션은 사용자를 ID 제공자로 리디렉션합니다. 제공자 측에는 이미 활성 세션이 존재하기 때문에 로그인 요청을 건너뛰고, 사용자의 신원을 확인하는 서명된 토큰을 반환합니다. 이것이 바로 여러 시스템이 뒤에서 서로 연동되고 있음에도 불구하고, SSO가 마치 한 번의 로그인처럼 느껴지게 하는 이유입니다.

SSO 토큰은 신원 제공자가 서비스 제공자에게 전송하여 사용자가 인증되었음을 확인하는, 서명된 작은 데이터 조각입니다. 이 토큰에는 일반적으로 사용자의 식별자, 발급 신원 제공자, 토큰 발급 시간 등의 정보가 포함됩니다. 토큰은 초기 구성 과정에서 교환된 인증서를 사용하여 디지털 서명되며, 이를 통해 서비스 제공자는 토큰이 실제로 신뢰할 수 있는 출처에서 왔으며 변조되지 않았음을 확인할 수 있습니다. 이러한 서명이 없다면 공격자가 토큰을 위조하여 임의의 사용자로 가장할 수 있으므로, 토큰 관리 및 수명 주기 제어는 기본 프로토콜만큼이나 중요합니다.

SSO는 단일 기술이 아닙니다. SSO는 소수의 명확하게 정의된 프로토콜을 기반으로 하며, 각 프로토콜은 고유한 장점과 대표적인 사용 사례를 가지고 있습니다. 이러한 프로토콜을 이해하면 공급업체를 평가하거나 기존 애플리케이션과 통합할 때 도움이 됩니다.

• SAML (보안 어설션 마크업 언어): 기업 애플리케이션 간의 웹 기반 SSO에 널리 사용되는 XML 기반 표준입니다. SAML은 SaaS 애플리케이션을 위한 기업용 SSO의 기반이 되는 가장 일반적인 프로토콜입니다.
• OAuth 2.0: 위임형 인증을 위한 프레임워크. OAuth를 사용하면 한 애플리케이션이 사용자의 인증 정보를 공유하지 않고도 다른 애플리케이션에 사용자 데이터에 대한 제한된 접근 권한을 부여할 수 있습니다. 이는 많은 최신 웹 및 모바일 인증 흐름의 기반이 되는 기술입니다.
• OpenID Connect (OIDC): OAuth 2.0을 기반으로 구축된 인증 계층입니다. OIDC는 OAuth의 승인 모델에 신원 확인 기능을 추가하며, 클라우드 애플리케이션, 모바일 앱 및 소비자 대상 서비스 전반에 걸쳐 SSO(단일 로그인)에 널리 사용됩니다.
• Kerberos: 대칭 키 암호화와 신뢰할 수 있는 제3자를 활용하여 시스템 전반에 걸쳐 사용자를 인증하는 티켓을 발급하는 네트워크 인증 프로토콜입니다. Kerberos는 온프레미스 Windows 환경에서 흔히 사용되며, 내부 SSO의 기반 계층으로 자주 활용됩니다.

대부분의 기업용 SSO 구축 환경에서는 클라우드 및 웹 애플리케이션에 SAML이나 OIDC를 사용하며, 온프레미스 시스템은 Kerberos나 관련 디렉터리 프로토콜을 통해 처리합니다. 유능한 ID 제공자는 이 모든 프로토콜을 지원하므로, 전체 애플리케이션 포트폴리오에서 SSO가 일관되게 작동할 수 있습니다.

SSO는 보안 및 운영 관련 의사결정이 이루어지는 곳을 통합하기 때문에 업무 환경에서 필수적인 요소가 되었습니다. 각 애플리케이션이 자체적인 로그인 및 정책 로직을 보유하는 대신, 인증은 한 곳에서 이루어지고, 정책은 한 번만 적용되며, 단일 제어 지점에서 전체 애플리케이션 포트폴리오에 걸쳐 접근 권한을 부여하거나 취소할 수 있습니다. 

• 비밀번호 수 감소: SSO는 사용자가 여러 애플리케이션에서 관리하거나 재사용해야 하는 비밀번호의 수를 줄여줍니다. 최고의 SSO 솔루션은 SSO 포털 자체에 비밀번호 없이 인증할 수 있도록 하여 비밀번호를 완전히 없애줍니다. 중앙 집중식 정책 적용: 비밀번호 규칙, 다단계 인증(MFA) 요구 사항, 세션 시간 제한 및 액세스 정책은 애플리케이션별로 개별적으로 구성하는 대신 한 곳에서 일괄적으로 적용됩니다.
• MFA 계층화를 위한 핵심 사항 하나: SSO 계층에서 MFA를 추가하면 연결된 모든 애플리케이션에 한 번에 더 강력한 인증이 적용됩니다.
• 신입사원 입사 및 퇴사 절차의 신속화: 사용자가 조직에 가입하거나 탈퇴할 때, 단일 제어 지점에서 연결된 모든 애플리케이션에 대한 접근 권한을 부여하거나 취소할 수 있습니다.
• 헬프데스크 업무 부담 감소: 비밀번호 수가 줄어들면 비밀번호 재설정 횟수도 줄어들게 되어, IT 부서가 더 가치 있는 업무에 집중할 수 있게 됩니다.
• 더 나은 사용자 경험: 직원들은 출근 기록에 드는 시간을 줄이고 업무 수행에 더 많은 시간을 할애합니다.

SSO는 단일 로그인 이벤트에 막대한 가치를 집중시키는데, 바로 그 지점에 대부분의 위험도 도사리고 있습니다. SSO의 관리를 용이하게 하는 바로 그 통합 특성 때문에, 인증 정보가 유출되거나 신뢰 관계가 잘못 구성되거나 신원 제공자(IDP)에 장애가 발생하면 연결된 모든 애플리케이션에 한꺼번에 연쇄적인 영향을 미칠 수 있습니다. 그렇다고 해서 SSO를 피해야 하는 것은 아닙니다. 오히려 이것이 바로 SSO를 신중하게 설계하고 보강해야 하는 이유입니다.

• 유일한 타협점: 공격자가 사용자의 SSO 인증 정보를 탈취할 경우, 연결된 모든 애플리케이션에 접근할 수 있게 될 수 있습니다. 따라서 SSO 로그인 자체의 보안 강도는 매우 중요합니다.
• Identity provider availability: If the identity provider goes down, users may be unable to sign in to connected applications. High availability and resilience are core requirements for any SSO deployment.
• Misconfiguration risk: SSO relies on trust relationships and certificates. Mistakes during setup, expired certificates, or poorly scoped permissions can create access gaps or expose applications.
• Recovery and fallback: A weak account recovery process can undo the security benefits of SSO. If a user can recover access through a weak help desk workflow, the strong front door does not matter.
• Not all applications support modern SSO: Legacy applications may not support SAML, OIDC, or Kerberos, which can force workarounds that weaken the overall posture.

SSO and other systems

The most important point about SSO risk is that SSO on its own is not enough. SSO confirms that the right credentials were entered. It does not, by itself, confirm that the right person entered them. That is why most enterprises pair SSO with 다단계 인증, adaptive or risk-based policies, device posture checks, and identity governance. SSO and MFA are complementary: SSO simplifies the sign-in event, and MFA strengthens it. 

SSO is rarely deployed on its own. It works best as one layer inside a broader identity and access strategy, and where it fits matters as much as how it is configured.

SSO and IAM

SSO is a component of identity and access management, not a replacement for it. IAM is the broader discipline that covers who someone is, what they are allowed to do, and what happens to their access over time. SSO handles the authentication event itself, simplifying how users prove who they are across the application portfolio. A strong identity program uses SSO as the front door and IAM as the framework around it.

SSO and Zero Trust

제로 트러스트 assumes no user, device, or session should be trusted by default, even inside the corporate network. SSO supports that model by giving security teams a consistent place to verify users before access is granted, and by making it easier to enforce MFA, adaptive policies, and session controls at every sign-in. SSO on its own does not deliver Zero Trust, but it is one of the controls Zero Trust architectures depend on.

SSO and identity governance

Authentication confirms that a user is who they claim to be. Identity governance decides whether that user should have access in the first place, whether the access is still appropriate, and when it should be revoked. SSO and ID 거버넌스 work together: SSO is the access layer, governance is the oversight layer that keeps the access layer aligned with policy, risk, and compliance requirements over time.

Implementing SSO is part technology project and part identity strategy decision. The technology side involves selecting an identity provider, defining trust relationships with each application, configuring user directories, and rolling out authentication policies. The strategy side involves deciding which applications belong inside the SSO perimeter, how recovery and exception handling will work, and how SSO will interact with MFA and governance.

A practical implementation usually moves through these steps:

1. Inventory the applications that should be brought under SSO, prioritizing high-value and high-risk systems first.
2. Choose an identity provider that supports the protocols those applications use (typically SAML, OIDC, and Kerberos).
3. Connect the identity provider to authoritative user directories so identities, attributes, and group memberships flow consistently.
4. Configure trust relationships, certificates, and attribute mapping for each application.
5. Define authentication policies, including MFA requirements, session length, and adaptive risk signals.
6. Pilot with a small user group, then roll out in phases.
7. Establish ongoing processes for adding new applications, rotating certificates, and reviewing access.

Choosing an SSO vendor is mostly about fit with the environment the vendor will be deployed into. A few criteria matter more than others:

• Broad protocol support: SAML, OIDC, OAuth 2.0, and Kerberos at minimum, so the SSO layer can cover both modern SaaS and legacy on-premises applications.
• Strong authentication options: Native MFA, adaptive authentication, and passwordless support, so SSO is not the weak link in the chain.
• Deployment flexibility: Cloud, hybrid, on-premises, and high-assurance options for organizations that operate across regulated or sovereign environments.
• Integration with identity governance: SSO should connect to identity lifecycle, access reviews, and policy management, not stand apart from them.
• Resilience and availability: High-availability architecture and clear disaster recovery posture, since SSO sits in the critical path for workforce access.
• A clear roadmap toward passwordless: SSO is often the first step in modernizing authentication, and the vendor should be able to support the next steps.

SSO is one of the highest-leverage controls in an identity program. It simplifies access for users, gives security teams a single point to apply stronger policies, and creates the foundation for MFA, adaptive authentication, and passwordless authentication. But the value of SSO depends on the strength of the sign-in behind it, the protocols it supports, and how well it integrates with the rest of the identity stack.

RSA helps organizations deliver SSO as part of a complete identity strategy, with the authentication, governance, and deployment flexibility enterprises need across cloud, hybrid, on-premises, and high-assurance environments. To see how it fits your organization, explore RSA single sign-on 및 identity management solutions.