싱글 사인온(SSO)이란?

싱글 사인온(SSO)은 ID 공급자에서 한 번 로그인하면 서로 독립된 여러 애플리케이션에 접근할 수 있게 하는 인증 방식입니다. 등장하는 역할은 둘입니다. ID 공급자(IdP)는 사용자를 인증하고 그 신원을 보증하며, 각 서비스 공급자(SP), 즉 사용자가 실제로 쓰려는 앱은 자체 로그인을 운영하는 대신 그 보증을 신뢰합니다. 짚어 둘 만한 엄밀한 구분이 하나 있습니다. 여러 앱이 디렉터리를 공유하면서도 각자 비밀번호를 묻는다면 그것은 동일 사인온(same sign-on)이고, 진정한 SSO는 한 번만 묻습니다.

핵심 요약

리디렉션 절차, 단계별로

애초에 리디렉션이 왜 필요합니까? 브라우저의 동일 출처 정책 때문입니다. app.example.com은 idp.example.org의 로그인 쿠키를 읽을 수 없으므로, 신원은 공유 쿠키가 아니라 브라우저를 거쳐 가는 서명된 메시지로 이동해야 합니다. 흐름이 하는 일이 정확히 그것입니다:

1  사용자가 app.example.com을 엶 – 세션 없음
2  SP가 인증 요청과 함께 IdP로 리디렉션
3  사용자가 IdP에서 직접 인증(비밀번호 + MFA) – 또는 이미
   IdP 세션이 있어 이 단계가 조용히 생략됨
4  IdP가 서명된 어설션(SAML XML) 또는 ID 토큰(OIDC JWT)을 발급
5  브라우저가 이를 SP의 콜백 URL로 전달
6  SP가 검증: 서명 · 발급자 · 대상 · 만료 · 재전송
7  SP가 자체 로컬 세션을 시작 – 사용자 로그인 완료
8  다음 앱: 1–2단계 후, 3단계의 조용한 경로에서 곧바로 7단계로

백엔드가 이 과정을 감싸 처리할 때 서비스 공급자 쪽 코드는 다음과 같습니다.

// JavaScript / Node.js — Back4app JS SDK
// Enterprise SSO: the IdP authenticates; the app trusts its signed token
// After the OIDC redirect dance, the client holds the IdP's tokens:
const user = await Parse.User.logInWith('keycloak', {
  authData: {
    id: subClaim,              // the IdP's stable subject ID
    access_token: accessToken, // verified server-side against the IdP
  },
});
// One IdP login now serves every app that trusts the same issuer.

// Flutter / Dart — Back4app Flutter SDK
// Enterprise SSO: the IdP authenticates; the app trusts its signed token
// After the OIDC redirect dance, the client holds the IdP's tokens:
final user = ParseUser.forQuery();
final response = await user.loginWith('keycloak', {
  'id': subClaim,              // the IdP's stable subject ID
  'access_token': accessToken, // verified server-side against the IdP
});
// One IdP login now serves every app that trusts the same issuer.

// iOS / Swift — Back4app Swift SDK
// Enterprise SSO: the IdP authenticates; the app trusts its signed token
// After the OIDC redirect dance, the client holds the IdP's tokens:
let user = try await User.loginWith(
    "keycloak",
    authData: [
        "id": subClaim,              // the IdP's stable subject ID
        "access_token": accessToken  // verified server-side against the IdP
    ]
)
// One IdP login now serves every app that trusts the same issuer.

// Android / Kotlin — Back4app Android SDK
// Enterprise SSO: the IdP authenticates; the app trusts its signed token
// After the OIDC redirect dance, the client holds the IdP's tokens:
val authData = mapOf(
    "id" to subClaim,              // the IdP's stable subject ID
    "access_token" to accessToken  // verified server-side against the IdP
)
ParseUser.logInWithInBackground("keycloak", authData).continueWith { task ->
    val user = task.result
    // One IdP login now serves every app that trusts the same issuer.
}

SP 시작 방식 vs. IdP 시작 방식

대부분의 설명은 첫 번째만 다루고 두 번째는 이름조차 언급하지 않습니다. 그러나 엔터프라이즈 IdP는 대시보드 타일을 좋아하므로 SP는 둘 다 마주치게 됩니다. SAML 기술 개요는 두 프로파일을 모두 규정하며, 실무 규칙은 표의 마지막 행에 있습니다.

SAML vs. OIDC

그리고 약어의 실타래를 푸는 삼각형을 한 번만 정리하면 이렇습니다. SAML과 OIDC는 SSO를 위한 인증을 수행하고, OAuth 2.0 단독으로는 인가 프로토콜입니다. OIDC는 OAuth의 메커니즘을 로그인에 안전하게 쓸 수 있도록 만든 신원 계층입니다. 소셜 로그인은 같은 OIDC 메커니즘에서 소비자 플랫폼이 IdP가 되고 하나의 앱이 대상이 되는 경우이며, 엔터프라이즈 SSO는 IdP의 운영 주체를 조직으로 바꾸고 세션을 제품군 전체로 넓힌 것입니다.

아무도 언급하지 않는 부분

단일 로그아웃(SLO)이 더 어려운 쪽입니다. 로그인은 하나의 IdP로 모여들지만, 로그아웃은 로컬 세션을 가진 모든 SP로 퍼져 나가야 합니다. 그리고 앱 하나가 응답하지 않으면 사슬이 끊어지고, 브라우저의 서드파티 쿠키 제한은 프론트 채널 알림을 깨뜨리며, 다른 디바이스에는 아무것도 전달되지 않습니다. 실제로 “모든 곳에서 로그아웃”이란 신뢰할 수 있는 브로드캐스트가 아니라, (종료된) IdP 세션을 다시 확인하는 짧은 로컬 세션을 뜻합니다. 세션은 세 개의 시계로 움직입니다. IdP의 전역 세션, 각 앱의 로컬 세션, 그리고 어설션 자체의 유효 기간입니다. IdP 세션이 살아 있는 동안 앱에서 로그아웃하면 다음 방문 때 조용히 다시 로그인됩니다. 사용자는 이를 버그로 신고하지만, 아키텍트는 이것이 설계임을 알아야 합니다. 그리고 SSO 세금이 있습니다. SaaS 벤더들은 SAML/SSO 지원을 기본 요금의 몇 배에 이르는 엔터프라이즈 등급 뒤에 두는 경우가 흔합니다. 보안 팀의 요구 사항과 구매 품목이 함께 도착하므로, 예산에 반영해 둘 만한 시장의 현실입니다.

영향 범위, 정직하게

SSO는 의도적으로 위험을 집중시킵니다. “싱글”의 의미가 바로 그것입니다. 탈취된 IdP 계정 하나는 연결된 모든 앱을 엽니다. 탈취된 IdP 자체는, 어설션 서명 키를 도난당하는 “골든 어설션” 공격 패턴을 포함해, 누구에게든 어디서든 유효한 신원을 찍어 낼 수 있습니다. 벤더들은 이 점을 완곡하게 표현하지만, 엔지니어링의 답은 그 집중을 현명하게 활용하는 것입니다. IdP에서의 피싱 방지 MFA(하나의 로그인이 이제 패스키 수준의 보호를 받을 가치가 있습니다), 하나의 포괄적 세션 대신 민감한 앱을 위한 단계적 인증, 위험이 큰 곳에서의 짧은 전역 세션, 서명 키 회전과 모니터링, 그리고 IdP가 다운되는 날을 위한 비상용 로컬 계정입니다. 단일 장애점은 결코 사라지지 않습니다. 대신 그 지점의 방어를 집중적으로 강화합니다. 한 지점만 강화하면 된다는 것이야말로 SSO가 약속한 경제성이기 때문입니다.

서비스 공급자로서의 통합

“SSO를 지원합니다”라는 말이 앱 팀에 실제로 요구하는 것을 하나의 목록으로 정리하면 다음과 같습니다. 콜백/ACS URL을 IdP에 등록하고 메타데이터(발급자, 인증서)를 교환합니다. 모든 어설션마다 서명, 발급자, 대상, 만료, 재전송 결속을 빠짐없이 검증합니다. IdP의 클레임을 사용자 모델에 매핑하되, 키는 이메일만이 아니라 안정적인 주체 ID여야 합니다. JIT(just-in-time) 프로비저닝으로 첫 SSO 로그인 때 로컬 사용자를 생성합니다. IdP 시작 방식으로 들어오는 어설션을 의도적으로 처리합니다. 그리고 로그아웃에 대한 기대치를 위에서 설명한 세 시계의 현실에 비추어 테스트합니다. 많은 팀이 걸어 온 길이며, 그래서 핸드셰이크의 반대편을 위한 Keycloak 같은 오픈소스 IdP가 존재합니다. 그러나 건너뛴 항목 하나하나가 언젠가 반드시 지적될 보안 취약점이 됩니다.

일반적인 사용 사례

• 임직원용 앱 제품군 – 대표적인 경우입니다. 아침에 한 번 로그인하면 그 뒤로 모든 내부 도구와 SaaS 도구가 열립니다.
• 대기업 시장으로 진출하는 B2B SaaS – “SSO 지원”은 엔터프라이즈 계약의 관문이 되는 체크박스입니다.
• 교육과 의료 – 기관 간 연합 접근으로, SAML의 뿌리가 가장 깊은 분야입니다.
• 중앙 집중식 MFA와 오프보딩 – 인증 요소를 강제하는 단일 지점이자, 퇴사자의 접근을 모든 곳에서 끊는 단일 스위치입니다.
• 다중 앱 제품 – 자체 제품군이 자체 IdP를 통해 소비자 방식으로 하나의 로그인을 공유합니다.

SSO를 도입해야 할까? 결정 매트릭스

한계와 트레이드오프

• 가용성은 신원과 함께 집중됩니다. IdP의 다운타임은 모두의 로그인 장애입니다. 이중화와 비상 경로는 기능에 덧붙이는 것이 아니라 기능의 일부입니다.
• 로그아웃은 로그인보다 약합니다. SLO의 팬아웃은 구조적으로 부분적인 실패를 피할 수 없습니다. 실제 보장을 제공하는 것은 로그아웃 브로드캐스트가 아니라 짧은 로컬 세션입니다.
• 롱테일은 비밀번호로 남습니다. SSO를 지원하지 않는 앱은 자체 자격 증명을 유지하며, 비밀번호 관리자가 여전히 그 뒷정리 계층을 맡습니다.
• 세션 계층 구조는 사용자를 혼란스럽게 합니다. 조용한 재로그인과 “로그아웃했는데 안 됐다”는 티켓은 세 시계 설계의 UX 비용이며, 문서화와 예측 가능한 타임아웃이 그 비용을 줄여 줍니다.
• 통합 품질은 SP마다 다릅니다. SSO의 보안 상한은 연결된 앱 중 가장 허술한 어설션 검증이 결정합니다. 위의 체크리스트는 앱마다, 그리고 영구히 적용됩니다.

Back4app에서의 SSO

Back4app은 관리형 데이터베이스, 자동 생성되는 REST 및 GraphQL API, 인증, 파일 스토리지, Cloud Code 서버리스 함수를 결합한 오픈소스 Backend as a Service(BaaS) 플랫폼입니다. 이곳의 앱은 소셜 로그인을 구동하는 것과 같은 어댑터 메커니즘을 통해 서비스 공급자로서 SSO 환경에 합류합니다. Back4app은 Keycloak, LDAP, 범용 OAuth2/OIDC 발급자용 인증 어댑터를 제공하므로, 코드 탭의 흐름(IdP가 인증하고, 앱이 토큰을 받으며, logInWith가 서버 측에서 발급자를 통해 토큰을 검증하는 흐름)이 엔터프라이즈 SSO를 설정과 리디렉션 핸들러 하나로 바꿉니다. 신원은 제공업체별 authData에서 IdP의 안정적인 주체 ID를 키로 하고, 첫 로그인이 사용자를 JIT 방식으로 프로비저닝하며, linkWith는 비상 경로를 위한 추가 방법을 연결하고, 앱이 발급하는 세션은 폐기 가능한 Parse 세션으로 유지됩니다. 따라서 세 시계로 이루어진 계층 구조에서 앱 쪽의 마지막 시계는 여러분이 완전히 통제할 수 있습니다.