What does SSO stand for, and what problem does it solve?

SSO stands for Single Sign-On. It is an authentication pattern that lets a user sign in once with their corporate identity provider and then access multiple downstream applications — including SecureCodingHub — without re-entering credentials. The point is not just convenience; it lets your security team enforce password policy, MFA, and offboarding in one place rather than per-application.

SSO vs SAML — are they the same thing?

No. SSO is the user-facing pattern; SAML is one of the protocols that can implement it. When you compare SSO vs SAML, the cleaner framing is that SAML 2.0 is a federation standard that carries the authentication assertion from your identity provider to the application, and SecureCodingHub speaks it. OIDC (built on OAuth 2.0) is the modern alternative for the same SSO outcome.

SSO vs OAuth — what is the actual difference?

The SSO vs OAuth distinction trips people up because OIDC sits on top of OAuth 2.0. OAuth 2.0 by itself is an authorization framework — it grants an application access to a resource. OIDC adds an identity layer on top, which is what makes OAuth-based SSO possible. So OAuth 2.0 alone does not give you SSO; OIDC over OAuth 2.0 does.

Can I use SSO with an open source identity provider?

Yes. Because SecureCodingHub supports the open standards — SAML 2.0 and OIDC — any open source SSO identity provider that implements them works. Keycloak, Authentik, and Zitadel are common picks for teams that want to self-host the IdP. The configuration steps on the SecureCodingHub side are identical to those for Azure AD or Okta; you supply the metadata or discovery URL and map the attributes.

SSO 개요

SecureCodingHub는 OpenID Connect (OIDC) 및 SAML 2.0을 통해 통합 로그인을 지원합니다. SSO를 사용하면 팀이 별도의 비밀번호 없이 기업 신원 공급자로 로그인할 수 있습니다.

지원되는 프로토콜

SecureCodingHub는 두 가지 업계 표준 SSO 프로토콜을 지원합니다:

OIDC (OpenID Connect)

OAuth 2.0 기반의 최신 프로토콜입니다. Azure AD, Okta 및 대부분의 클라우드 신원 공급자에 권장됩니다. PKCE와 함께 authorization code flow를 사용합니다.

SAML 2.0

XML 기반 페더레이션 프로토콜입니다. 레거시 신원 공급자 및 엔터프라이즈 환경에 지원됩니다.

SSO 작동 방식

조직에 SSO가 구성되면, 로그인 흐름은 다음과 같이 작동합니다:

사용자가 SecureCodingHub 로그인으로 이동

조직의 SSO 진입점에 도착(링크에는 조직 식별자가 포함되어 있습니다. 오늘 자동 이메일 도메인 감지는 없습니다)

브라우저가 신원 공급자(Azure AD, Okta 등)로 리다이렉트

사용자가 기업 자격 증명으로 인증

IdP가 인증 토큰과 함께 SecureCodingHub로 다시 리다이렉트

SecureCodingHub가 세션을 생성하고 사용자를 로그인시킴

JIT 프로비저닝

SSO가 활성화되면 첫 로그인 시 사용자가 자동으로 생성됩니다 — 이를 Just-In-Time (JIT) 프로비저닝이라고 합니다. 새 사용자는 기본적으로 학습자 역할을 할당받습니다. 새 사용자가 프로비저닝되려면 조직에 사용 가능한 좌석이 있어야 합니다.

구성 URL

신원 공급자를 구성할 때 다음 URL을 사용하세요:

설정	값
OIDC 콜백 URL	`https://api.limeplate.com/api/sch/auth/sso/callback/oidc`
SAML ACS URL	`https://api.limeplate.com/api/sch/auth/sso/callback/saml`
SP 메타데이터 URL	`https://api.limeplate.com/api/sch/auth/sso/metadata`

참고: SSO 구성에는 조직 관리자 또는 플랫폼 관리자 액세스가 필요합니다. 시작하려면 Azure AD 또는 Okta 설정 가이드를 참조하세요.

SAML과 OIDC 사이의 선택

신원 공급자가 두 프로토콜을 모두 지원하는 경우, 실용적인 답은 보안 팀이 이미 운영하고 신뢰하는 것을 선택하는 것입니다. OIDC는 OAuth 2.0 기반의 새로운 JSON 기반 프로토콜입니다. 개발하기 친화적이고, 디버깅하기 쉽고, Azure AD와 Okta를 포함한 대부분의 최신 IdP에서 기본 옵션입니다. 클라우드 네이티브 도구로 표준화하는 조직의 경우, OIDC가 일반적으로 올바른 선택입니다.

SAML은 오래된 XML 기반 페더레이션 표준이며, 엔터프라이즈 환경에서 가장 흔한 선택으로 남아 있습니다. 그 이유는 거의 기술적 선호가 아닙니다. IdP 팀이 이미 수십 개의 SAML 통합을 실행하고 있고, 인증서 회전 일정이 확립되어 있으며, SAML 문제 해결을 위한 내부 플레이북이 성숙해 있기 때문입니다. PingFederate, ADFS 또는 레거시 SAML IdP가 있는 환경에 배포하는 경우, SAML을 선택하면 IdP 팀에 일회성 OIDC 통합을 지원하도록 요청하는 대신 기존 패턴을 재사용할 수 있습니다. 두 프로토콜 모두 동등한 보안을 제공합니다. 선택은 암호화가 아니라 운영 적합성에 관한 것입니다.

SSO 사전 체크리스트

프로덕션에서 SSO를 활성화하기 전에 세 가지 현실을 중심으로 계획하세요. 첫째, 테스트 환경을 설정하거나 처음부터 끝까지 제어하는 테넌트를 사용하세요. 잘못 구성된 SSO는 그것을 구성한 관리자를 포함하여 모든 사람을 잠글 수 있습니다. 이상적으로는 일회용 IdP 애플리케이션과 함께 중요하지 않은 조직에 대해 전체 로그인 흐름을 먼저 실행하여 긴급함 없이 속성 매핑을 반복할 수 있습니다. 둘째, SSO에 의존하지 않는 하나 이상의 폴백 관리자 계정을 유지하세요. SecureCodingHub는 비상 로컬 관리자 경로를 존중하며, 이를 테스트할 시간은 SSO가 라이브되기 전이지 금요일 저녁 9시에 무언가가 잘못된 후가 아닙니다.

셋째, 이메일 기반 초대 흐름에 대한 다운스트림 영향을 생각해 보세요. SSO가 활성화되면 검증된 도메인의 사용자가 IdP로 리다이렉트되고 첫 로그인 시 JIT 프로비저닝됩니다. 이는 이메일로 사용자를 수동으로 초대하는 관리자와 IdP에서 앱을 할당하는 디렉터리 관리자가 모두 계정을 생성할 수 있고, 둘 중 하나를 선택하지 않으면 두 스트림이 충돌함을 의미합니다. 더 깨끗한 패턴은 SSO 관리 도메인에 대해 수동 초대를 비활성화하고 IdP가 단일 진실의 출처가 되도록 하는 것입니다. 다음 단계는 SAML 설정 가이드 및 프로토콜별 가이드를 참조하세요.

SSO: 자주 묻는 질문

SSO는 무엇의 약자이며 어떤 문제를 해결합니까?

SSO는 Single Sign-On의 약자입니다. 사용자가 기업 신원 공급자로 한 번 로그인하면 자격 증명을 다시 입력하지 않고 SecureCodingHub를 포함한 여러 다운스트림 애플리케이션에 액세스할 수 있도록 하는 인증 패턴입니다. 요점은 편의성뿐만이 아닙니다 — 보안 팀이 애플리케이션별이 아닌 한 곳에서 비밀번호 정책, MFA 및 오프보딩을 시행할 수 있게 해줍니다.

SSO와 SAML — 같은 것입니까?

아닙니다. SSO는 사용자 대면 패턴이고, SAML은 이를 구현할 수 있는 프로토콜 중 하나입니다. SSO와 SAML을 비교할 때, 더 깨끗한 프레임은 SAML 2.0이 신원 공급자에서 애플리케이션으로 인증 어설션을 전달하는 페더레이션 표준이며 SecureCodingHub가 이를 말한다는 것입니다. OIDC(OAuth 2.0 기반)는 동일한 SSO 결과를 위한 최신 대안입니다.

SSO와 OAuth — 실제 차이점은 무엇입니까?

OIDC가 OAuth 2.0 위에 있기 때문에 SSO와 OAuth의 구분이 사람들을 혼란스럽게 합니다. OAuth 2.0 자체는 인가 프레임워크입니다 — 애플리케이션에 리소스에 대한 액세스를 부여합니다. OIDC는 그 위에 신원 계층을 추가하며, 이것이 OAuth 기반 SSO를 가능하게 합니다. 따라서 OAuth 2.0만으로는 SSO를 제공하지 않습니다. OAuth 2.0 위의 OIDC가 그렇게 합니다.

오픈 소스 신원 공급자와 함께 SSO를 사용할 수 있습니까?

예. SecureCodingHub가 개방형 표준 — SAML 2.0 및 OIDC — 을 지원하기 때문에 이를 구현하는 모든 오픈 소스 SSO 신원 공급자가 작동합니다. Keycloak, Authentik 및 Zitadel은 IdP를 자체 호스팅하려는 팀에게 일반적인 선택입니다. SecureCodingHub 측의 구성 단계는 Azure AD 또는 Okta와 동일합니다. 메타데이터 또는 디스커버리 URL을 제공하고 속성을 매핑합니다.