Contents
1. SSO(Single Sign-On)
2. 인증과 인가
3. SSO 동작 방식
1. SSO(Single Sign-On)
한 번의 사용자 인증으로 여러 서비스에 접근할 수 있게 하는 통합 인증 방식
사용자는 서비스마다 아이디와 비밀번호를 입력하지 않아도 되고, 서비스 개발자는 각 서비스마다 로그인 로직을 중복 구현하지 않아도 된다.
1.1 SSO의 개념
Single Sign-On의 약자로, 사용자가 한 번 로그인하면 여러 독립된 서비스에 반복 로그인 없이 접근할 수 있게하는 인증 체계
예를 들어, 회사에 다음과 같은 시스템이 있다고 가정한다.
- 그룹웨어
- 인사 시스템
- 메일 시스템
- 결재 시스템
- 사내 포털
기존 방식이라면 각 시스템마다 로그인해야 한다. 하지만 SSO를 적용한다면 사용자는 한 번 인증한 뒤 여러 시스템을 사용할 수 있다.
각 서비스가 직접 인증하지 않고,
공통 인증 서버에 사용자 인증을 위임한다.1.2 기존 로그인 방식의 문제
서비스 수가 늘어날수록 인증 로직이 중복되고 관리 복잡도가 증가한다.
예시:
- 서비스 A → 로그인 기능 보유
- 서비스 B → 로그인 기능 보유
- 서비스 C → 로그인 기능 보유
사용자 입장:
- 여러 서비스의 아이디와 비밀번호를 기억해야 한다.
- 서비스마다 로그인해야 하므로 사용성이 떨어진다.
개발자 입장:
- 각 서비스마다 로그인 화면, 인증 로직, 사용자 DB, 비밀번호 정책, 세션 관리 등을 따로 구현해야 한다.
운영 관점:
- 사용자 정보 동기화 필요
- 비밀번호 정책 통일 어려움
- 계정 잠금/탈퇴/권한 변경 반영이 어려움
- 보안 정책이 서비스마다 달라질 수 있음
- 장애 발생 시 원인 추적이 어려움
1.3 SSO 방식
인증의 중앙화, 공통 인증 서버가 인증을 담당한다.
각 서비스는 사용자를 직접 인증하지 않고, 공통 인증 서버에 인증을 맡긴다.
서비스 A
서비스 B → 공통 인증 서버
서비스 C- 사용자가 서비스 A에 접근한다.
- 서비스 A는 사용자가 로그인하지 않았음을 확인한다.
- 서비스 A는 사용자를 공통 인증 서버로 보낸다.
- 사용자는 인증 서버에서 로그인한다.
- 인증 서버는 인증 결과를 서비스 A에 전달한다.
- 서비스 A는 인증 결과를 검증한 뒤 서비스를 제공한다.
- 이후 서비스 B에 접근하면 이미 인증된 사용자인지 확인하고 로그인 과정을 생략할 수 있다.
1.4 SP, IdP, Authorization Server
SP: 사용자가 접근하는 서비스 IdP: 사용자를 인증하는 서버 Authorization Server: 토큰을 발급하는 서버
IdP와 Authorization Server가 같은 시스템에서 함께 동작하는 경우가 많다.
1.4.1 SP(Service Provider)
사용자가 실제로 이용하려는 서비스,
예를 들면 그룹웨어, 메일, 인사 시스템, 결재 시스템 등이 SP다. SP는 사용자를 직접 인증하지 않고, IdP에 인증을 맡긴다.
1.4.2 IdP(Identity Provider)
사용자의 신원을 확인해주는 인증 제공자,
IdP는 사용자의 아이디, 비밀번호, OTP, FIDO, 생체인증 등을 통해 사용자가 누구인지 확인한다. IdP에 장애가 발생하면 여러 서비스의 로그인 흐름에 영향이 간다.
1.4.3 Authorization Server
OAuth 2.0 / OIDC 환경에서 토큰을 발급하는 서버
Authorization Server는 사용자의 인증과 동의를 바탕으로 Access Token, ID Token, Refresh Token 등을 발급한다. Keycloak, Spring Authorization Server 같은 도구가 Authorization Server 역할을 할 수 있다.
2. 인증과 인가
인증(Authentication): 너 누구야? 인가(Authorization): 너 이 기능 써도 돼?
2.1 인증(Authentication)
사용자가 누구인지 확인하는 과정 사용자의 신원을 확인하는 것
예시:
- 아이디/비밀번호 로그인
- OTP 인증
- FIDO 인증
- 생체인증
- 사원증 기반 인증
2.2 인가(Authorization)
인증된 사용자가 특정 리소스나 기능에 접근할 권한이 있는지 확인하는 과정
예시:
- 일반 사용자는 관리자 페이지 접근 불가
- 인사팀만 급여 정보 조회 가능
- 특정 부서만 결제 문서 승인 가능
- 로그인은 했지만 해당 API 호출 권한은 없음
인증이 끝났다고 해서 모든 기능을 사용할 수 있는 것은 아니다.
2.3 OAuth 2.0: 권한 위임을 위한 인가 프로토콜
OAuth 2.0은 사용자의 계정 정보를 직접 넘기지 않고, 특정 리소스에 접근할 권한만 위임하는 인가 프로토콜이다.
OAuth 2.0의 핵심은 “로그인”이 아니라 권한 위임이다.
예시(어떤 서비스가 사용자의 Google 연락처에 접근하려는 상황):
- 기존 방식
서비스에 Google 아이디와 비밀번호를 직접 알려준다.- 서비스가 계정 전체에 접근할 수 있다.
- 사용자의 비밀번호가 외부 서비스에 노출된다.
- 연락처 조회처럼 필요한 권한만 제한해서 줄 수 없다.
- OAuth 2.0 방식
사용자는 Google에서 직접 로그인한다.
Google은 사용자에게 권한 위임 여부를 묻는다.
사용자가 동의하면 서비스는 Access Token을 받는다.
서비스는 Access Token으로 허용된 리소스에만 접근한다.- OAuth 2.0은 비밀번호를 넘기지 않고, 필요한 권한만 제한적으로 위임한다.
OAuth 2.0: 인가(Authorization) Access Token: 리소스 접근 권한을 증명하는 토큰
2.4 OIDC: OAuth 2.0 위에 추가된 인증 계층
OIDC(OpenID Connect)는 OAuth 2.0 위에 사용자 인증 기능을 추가한 프로토콜이다.
OAuth 2.0은 인가 프로토콜이기 때문에, 사용자 인증을 표준화하기에는 부족하다.
OAuth 2.0의 Access Token은 기본적으로 다음을 의미한다.
- 이 토큰은 특정 리소스에 접근할 권한이 있다.
하지만 Access Token 만으로는 다음 질문에 명확히 답하기 어렵다.
- 이 사용자는 누구인가?
- 정말 로그인한 사용자인가?
- 사용자 식별 정보는 어떤 방식으로 확인해야 하는가?
OIDC는 OAuth 2.0의 흐름에 ID Token을 추가한다:
- OAuth 2.0
- Access Token 중심
- 리소스 접근 권한 확인
- OIDC
- Access Token + ID Token
- 리소스 접근 권한 + 사용자 신원 확인
ID Token의 역할:
- 사용자의 신원 정보를 담는 토큰
- 사용자 식별자
- 발급자
- 발급 시간
- 만료 시간
- 인증된 사용자 정보
OAuth 2.0: 권한 위임을 위한 인가 프로토콜 OIDC: OAuth 2.0 기반의 사용자 인증 프로토콜 Access Token: 리소스 접근 권한 확인 ID Token: 사용자 신원 확인
3. SSO 동작 방식
사용자가 서비스에 접근하고, 서비스가 인증 서버로 리다이렉트하고, 인증 서버가 인증 결과를 전달하고, 서비스가 자체 세션이나 토큰을 만드는 흐름으로 구성된다.
3.1 기본 로그인 흐름
3.2 Authorization Code Flow
OIDC 기반 SSO에서는 보통 Authorization Code Flow가 사용된다.
Authorization Code Flow는 사용자가 Authorization Server에서 로그인한 뒤,
서비스가 Authorization Code를 이용해 토큰을 발급받는 방식이다.
이 방식의 핵심은 Access Token을 브라우저로 직접 전달하지 않는 것이다.
3.2.1 Authorization Code란?
로그인 성공 후 Authorization Server가 브라우저를 서비스의 Redirect URI로 리다이렉트하면서 전달하는 일회성 임시 코드
Authorization Server → Browser → Service Redirect URI즉, Authorization Code는 Authorization Server가 서비스 서버에 직접 전달하는 값이 아니라,
브라우저를 거쳐 서비스 서버로 전달되는 값이다.
서비스 서버는 Redirect URI로 들어온 요청에서 Authorization Code를 추출하고,
이를 Token Endpoint로 보내 Access Token, ID Token, 필요 시 Refresh Token으로 교환한다.
3.2.2 Token Endpoint란?
Authorization Server가 제공하는 토큰 발급 API
Authorization Server:
- 인증/인가와 토큰 발급을 담당하는 서버
Token Endpoint:
- Authorization Server 안에 있는 토큰 발급용 API
서비스 서버는 브라우저를 통해 전달받은 Authorization Code를 Token Endpoint로 보내고,
Authorization Server는 해당 Code를 검증한 뒤 토큰을 발급한다.
3.2.3 Access Token을 브라우저로 바로 전달하지 않는 이유
Access Token은 실제 리소스 접근 권한을 가진 값이기 때문에, 브라우저로 직접 전달하지 않고 서버 간 통신으로 교환하는 것이 더 안전하다.
3.2.4 Authorization Code가 필요한 이유
브라우저 기반 로그인 흐름과 서버 간 토큰 발급 흐름을 안전하게 연결하기 위해 필요하다.
사용자는 Authorization Server에서 로그인하지만, 최종적으로 로그인 처리를 해야 하는 곳은 서비스 서버다.
따라서 서비스 서버는 전달받은 인증 결과가 자신이 시작한 로그인 요청에 대한 응답인지, 그리고 현재 브라우저 사용자 세션과 연결되는 결과인지 확인해야 한다.
만약 Authorization Server가 서비스 서버로 인증 결과나 토큰을 직접 전달한다면, 서비스 서버 입장에서는 다음을 확인하기 어려워진다.
- 이 인증 결과가 내가 시작한 로그인 요청의 결과인가?
- 이 인증 결과가 지금 이 브라우저 사용자의 세션과 연결되는가?
- 중간에 위조되거나 끼워 넣어진 응답은 아닌가?
Authorization Code Flow에서는 서비스가 로그인 요청을 시작할 때 state 같은 값을 함께 전달하고,
Authorization Server는 로그인 성공 후 Authorization Code와 state를 브라우저를 통해 서비스의 Redirect URI로 돌려보낸다.
서비스 서버는 state로 자신이 시작한 요청의 응답인지 확인하고,
Authorization Code를 Token Endpoint로 보내 실제 토큰을 발급받는다.
3.3 ID Token과 Access Token
OIDC 기반 SSO에서는 ID Token과 Access Token을 구분해야 한다.
ID Token:“이 사용자는 누구인가?” Access Token:“이 사용자는 이 리소스에 접근할 권한이 있는가?“
3.3.1 ID Token
사용자가 인증되었고, 그 사용자가 누구인지 알려주는 토큰
ID Token은 클라이언트가 사용자의 신원을 확인하는 데 사용한다.
ID Token의 목적:사용자 인증 결과 확인
예를 들면 다음과 같은 정보가 들어갈 수 있다.
- 사용자 식별자
- 발급자
- 대상자
- 발급 시간
- 만료 시간
- 이름, 이메일 등 사용자 정보
3.3.2 Access Token
리소스 서버에 접근할 권한을 증명하는 토큰
Access Token은 API나 Resource Server를 호출할 때 사용한다.
Access Token의 목적:리소스 접근 권한 증명
예를 들면 사용자가 로그인한 뒤, 사용자 정보 API나 업무 시스템 API를 호출할 때 Access Token을 사용한다.
3.4 SSO Session과 서비스 세션
SSO에서는 두 종류의 세션을 구분해야 한다.
- IdP의 SSO Session
- 각 서비스의 자체 세션
두 세션은 모두 로그인 상태와 관련이 있지만, 관리 주체와 역할이 다르다.
3.4.1 SSO Session
IdP가 관리하는 로그인 상태
사용자가 IdP에서 로그인에 성공했을 때 생성되는 세션이다.
- 사용자가 한 번 IdP에서 인증을 완료하면, IdP는 사용자가 이미 로그인한 상태임을 기억한다.
- 이후 사용자가 다른 서비스에 접근하더라도 IdP는 SSO Session을 확인하고, 아이디/비밀번호 입력 과정을 생략할 수 있다.
사용자 → 서비스 B 접근
서비스 B → IdP로 리다이렉트
IdP → SSO Session 확인
IdP → 이미 로그인된 사용자로 판단
IdP → 서비스 B에 인증 결과 확인 정보 전달
서비스 B → 자체 로그인 처리즉, SSO Session은 여러 서비스에서 공통으로 참고하는 인증 상태이다.
3.4.2 서비스 세션
각 SP가 자기 서비스 안에서 관리하는 로그인 상태
서비스 세션은 각 서비스가 자체적으로 관리하는 세션이다.
예를 들어 사용자가 그룹웨어에 로그인하면 그룹웨어는 그룹웨어 세션을 만들고, 인사 시스템에 접근하면 인사 시스템은 인사 시스템 세션을 만들 수 있다.
IdP:
- 사용자가 이미 인증되었는지 관리
SP:
- 자기 서비스에서 로그인 상태를 유지
즉 서비스 세션은 각 서비스 내부에서 사용자의 로그인 상태를 유지하기 위한 세션이다.
3.4.3 두 세션의 차이
SSO Session은 IdP가 관리하는 공통 인증 상태이고,
서비스 세션은 각 서비스가 관리하는 개별 로그인 상태이다.
SSO Session이 있다고 해서 모든 서비스가 같은 세션을 공유하는 것은 아니다.
사용자가 새로운 서비스에 접근하면 해당 서비스는 IdP의 SSO Session을 확인해 로그인 과정을 생략하고,
이후 자기 서비스의 세션을 별도로 생성한다.
SSO Session:
- IdP가 관리하는 로그인 상태
- “이 사용자가 인증 서버에서 이미 로그인했는가?”를 판단
서비스 세션:
- 각 서비스가 관리하는 로그인 상태
- “이 사용자가 우리 서비스에서 로그인 처리된 상태인가?”를 판단
1. SSO Session, 서비스 세션 둘다 없을 때(처음 로그인하는 상황)
- 이 경우 사용자는 완전히 로그인하지 않은 상태입니다.
흐름:
- 사용자 → 서비스 접근
- 서비스 → 서비스 세션 없음 확인
- 서비스 → IdP로 리다이렉트
- IdP → SSO Session 없음 확인
- IdP → 로그인 화면 표시
- 사용자 → 아이디/비밀번호 입력
- IdP → SSO Session 생성
- 서비스 → 인증 결과 확인 후 서비스 세션 생성
2. SSO Session 없고, 서비스 세션만 있을 때
예시:
- 사용자가 이미 서비스 A에 로그인해서 서비스 세션은 살아 있는데, IdP의 SSO Session은 만료되었거나 삭제된 경우
사용자 → 서비스 A 접근
서비스 A → 서비스 세션 있음 확인
서비스 A → 로그인된 사용자로 처리서비스 A 입장에서는 자기 세션이 살아 있으므로 사용자를 계속 로그인 상태로 볼 수 있다.
하지만 사용자가 서비스 B에 새로 접근하면:
사용자 → 서비스 B 접근
서비스 B → 서비스 세션 없음
서비스 B → IdP로 리다이렉트
IdP → SSO Session 없음
IdP → 로그인 화면 표시즉, 기존 서비스는 계속 쓸 수 있지만, 다른 서비스로 SSO 로그인은 안 될 수 있다.
3. SSO Session 있고, 서비스 세션 없을 때
예시:
- 사용자가 그룹웨어에서 로그인해서 IdP에 SSO Session이 생겼고, 이후 처음으로 인사 시스템에 접근하는 경우
사용자 → 인사 시스템 접근
인사 시스템 → 서비스 세션 없음 확인
인사 시스템 → IdP로 리다이렉트
IdP → SSO Session 있음 확인
IdP → 로그인 화면 생략
IdP → 인증 결과 전달
인사 시스템 → 자체 서비스 세션 생성아이디/비밀번호를 다시 입력하지 않고 서비스 세션이 새로 만들어진다.
4. SSO Session, 서비스 세션 둘 다 있을 때(해당 서비스에서 이미 로그인된 상태)
사용자 → 서비스 접근
서비스 → 서비스 세션 있음 확인
서비스 → 바로 서비스 제공보통 이 경우에는 굳이 IdP로 보내지 않는다.
서비스가 자기 세션만 확인하고 바로 로그인 상태로 처리합니다.
정리 표:
| 상태 | 의미 | 처리 |
|---|---|---|
| SSO Session 없음 + 서비스 세션 없음 | 완전 미로그인 | IdP 로그인 필요 |
| SSO Session 없음 + 서비스 세션 있음 | 해당 서비스에는 로그인됨, SSO는 끊김 | 기존 서비스는 사용 가능, 다른 서비스 접근 시 재로그인 가능 |
| SSO Session 있음 + 서비스 세션 없음 | IdP에는 로그인됨, 해당 서비스는 아직 로그인 안 됨 | IdP 로그인 생략 후 서비스 세션 생성 |
| SSO Session 있음 + 서비스 세션 있음 | IdP와 서비스 모두 로그인 상태 | 바로 서비스 이용 |
3.5 Single Sign-Out
한 서비스에서 로그아웃했을 때, 관련된 다른 서비스의 로그인 상태도 함께 종료되도록 하는 방식
SSO 환경에서는 여러 서비스가 하나의 인증 상태를 기반으로 동작하므로, 로그아웃 시 현재 서비스뿐 아니라 IdP와 다른 서비스의 세션까지 함께 고려해야 한다.
3.5.1 Front-Channel Logout
브라우저를 통해 각 서비스에 로그아웃 요청을 전달하는 방식
사용자 로그아웃 → IdP 로그아웃 처리 → 브라우저를 통해 각 서비스의 로그아웃 URL 호출 → 각 서비스 세션 종료
구조가 비교적 단순하지만 브라우저 상태에 영향을 받는다.
- 브라우저가 일부 요청을 차단하거나, 네트워크 문제로 특정 서비스의 로그아웃 요청이 실패하면 일부 서비스 세션이 남을 수 있다.
3.5.2 Back-Channel Logout
서버 간 통신으로 각 서비스에 로그아웃 요청을 전달하는 방식
Back-Channel Logout은 브라우저를 거치지 않고, IdP가 각 서버에 직접 로그아웃 요청을 전달하는 방식이다.
사용자 로그아웃 → IdP 로그아웃 처리 → IdP가 각 서비스 서버에 로그아웃 요청 전송 → 각 서비스 세션 종료
Front-Channel Logout 보다는 안정적이다.
- 사용자가 브라우저를 닫았거나, 일부 탭이 열려 있지 않은 상황에서도 서버 간 통신으로 로그아웃 전파 가능
3.5.3 토큰 기반 환경에서의 주의점
세션을 종료해도 Access Token이 바로 무효화되지 않을 수 있다.
OAuth 2.0 / OIDC 환경에서는 Access Token이 stateless하게 발급되는 경우가 많다.
즉, 서버가 매 요청마다 토큰 저장소를 확인하는 것이 아니라,
토큰 자체의 서명과 만료 시간만 검증해서 접근을 허용할 수 있다.
이 경우 로그아웃으로 세션을 종료하더라도, 이미 발급된 Access Token은 만료 전까지 사용이 가능하다.
따라서 로그아웃 시에는 Refresh Token을 반드시 무효화하고, Access Token은 만료 시간을 짧게 가져가는 것이 일반적이다.
또한 보안 요구사항이 높은 경우에는 Redis 등을 활용해 토큰 블랙리스트나 토큰 상태 관리 전략을 함께 적용할 수 있다.
1. IdP의 SSO Session 종료
2. 각 서비스의 서비스 세션 종료
3. Refresh Token 무효화
4. Access Token 만료 시간 짧게 설정
5. 필요 시 Redis 등을 활용한 토큰 상태 관리
6. 로그아웃 이벤트를 각 서비스에 전파