SSO(Single Sign-On)는
“한 번 로그인하면 여러 시스템을 다시 로그인하지 않고 이용하게 만드는 인증 구조”

대표적으로:

회사 포털 로그인
Jira / Confluence / GitLab / Slack 자동 로그인
“구글로 로그인”
“카카오 로그인”

이런 게 전부 SSO 개념

핵심 개념 먼저

SSO에서 가장 중요한 건:

“로그인을 누가 대신 해주느냐”

즉,

각각의 서비스가 직접 로그인 검증하지 않고
중앙 인증 서버(IdP)를 믿는 구조

야.

등장 인물

1. 사용자(User)

브라우저 사용하는 사람

2. 서비스 서버(SP)

실제 서비스를 제공하는 서버

예:

쇼핑몰
사내 그룹웨어
GitLab

SSO에서는 얘를 보통:

Service Provider
SP

라고 부름.

3. 인증 서버(IdP)

진짜 로그인 담당 서버

예:

구글 계정 서버
회사 인증 서버
Okta
Keycloak
Azure AD

SSO의 핵심.

보통:

Identity Provider
IdP

라고 부름.

가장 쉬운 예시

“구글로 로그인”

이걸로 이해하면 거의 끝남.

전체 흐름

STEP 1

사용자가 쇼핑몰 접속

shop.com

근데 로그인 안됨.

STEP 2

쇼핑몰이 말함

"나는 로그인 기능 직접 안할게
구글한테 인증 받아와"

브라우저를 구글 로그인 페이지로 리다이렉트.

STEP 3

사용자가 구글 로그인

gmail / password

입력.

STEP 4

구글이 로그인 성공 확인

그리고 말함:

"이 사용자는 진짜 인증됨"

이 정보를 토큰 형태로 만들어서
쇼핑몰에게 전달.

STEP 5

쇼핑몰은 구글을 믿음

토큰 검증 후:

아 인증된 사용자네

라고 판단.

자체 세션/JWT 발급.

왜 SSO가 되는가

핵심은:

브라우저에 구글 로그인 세션이 이미 있음

예를 들어:

Gmail 로그인 상태
YouTube 로그인 상태

면 이미:

accounts.google.com

세션 쿠키가 존재함.

그래서 다른 사이트에서:

구글 로그인 해줘

해도

구글이 이미 로그인된 사용자인 걸 알고 있음.

즉:

비밀번호 다시 안침

→ 이게 SSO.

실무에서 가장 중요한 포인트

SSO는 사실:

"인증 위임"

이다.

서비스는:

비밀번호 관리 안할게
인증은 중앙 서버가 해줘

하는 구조.

SSO의 장점

1. 로그인 한 번

사용자 편함.

2. 보안 강화

서비스마다 비밀번호 저장 안함.

중앙 인증만 관리.

3. 계정 관리 쉬움

회사 퇴사자:

IdP 계정 비활성화

하면 모든 시스템 접근 차단됨.

대표 프로토콜

SSO는 그냥 개념이고,
실제로는 프로토콜이 필요함.

1. OAuth2

권한 위임 중심

대표:

구글 로그인
카카오 로그인

2. OpenID Connect (OIDC)

OAuth2 위에 인증 기능 추가.

요즘 웹 서비스 SSO의 사실상 표준.

실무에서 제일 많이 씀.

3. SAML

기업용 레거시 SSO.

아직 대기업에서 많음.

XML 기반이라 무겁다.

OAuth2와 SSO 차이

이거 엄청 헷갈려함.

OAuth2

원래 목적:

권한 위임

예:

"내 구글 드라이브 접근 허용"

SSO

목적:

로그인 공유

근데 현실에서는:

OAuth2 + OIDC

조합으로 SSO 구현함.

실무 구조

요즘 가장 흔한 구조:

React/Vue 프론트
↓
Spring Boot API
↓
Keycloak / Auth0 / Okta

실제 로그인 흐름

1

프론트:

/login

누름.

2

백엔드 or 프론트가:

IdP 로그인 페이지로 redirect

3

IdP 로그인 성공

4

Authorization Code 발급

5

백엔드가 토큰 교환

Access Token
ID Token
Refresh Token

받음.

6

백엔드가 자체 세션/JWT 생성

또는 그대로 Access Token 사용.

ID Token 역할

OIDC 핵심.

예:

{
  "sub": "12345",
  "email": "abc@gmail.com",
  "name": "hoon"
}

즉:

"이 사용자는 누구인가"

증명.

보통 JWT 형식.

Access Token 역할

이건:

"무엇을 할 수 있는가"

권한 증명.

API 호출용.

회사 내부 SSO 예시

출근 후:

사내 포털 로그인

하면:

ERP
메신저
그룹웨어
GitLab

자동 로그인.

이건 전부:

중앙 인증 서버(IdP)

를 믿기 때문.

로그아웃은 왜 어려운가

SSO의 어려운 점.

왜냐면:

서비스 세션
IdP 세션

둘 다 존재하기 때문.

예:

쇼핑몰 로그아웃

했는데

구글 로그인 세션은 살아있음.

그러면 다시 로그인 시도하면 즉시 로그인됨.

그래서:

Single Logout(SLO)

라는 개념도 존재.

하지만 구현 난이도 높음.

실무에서 많이 쓰는 솔루션

오픈소스

Keycloak
Gluu Server

클라우드/상용

Okta
Auth0
Microsoft Entra ID

한 줄 핵심 정리

SSO는:

여러 서비스가
중앙 인증 서버(IdP)를 신뢰해서

사용자가 한 번 로그인하면
다른 서비스도 자동 로그인되는 구조

야.

저작자표시 (새창열림)