SSO(Single Sign-On)

SSO

: 한 번의 인증 과정(로그인)으로 여러 컴퓨터 상의 자원을 이용하게 해주는 인증 기능이다.

SSO 유무에 따른 서비스 처리 과정

장점

- 중앙집중 관리 > 개별 관리의 위험성 해소

- User의 편의성 증가

단점

- SSO 서버 침해 > 모든 서버의 보안 침해 가능

- 각각의 사이트의 보안 수준이 다르면, 보안에 문제가 생김

- SSO 서버가 단일 장애 지점(SPOF)

( SPOF : 시스템 구성 요소 중에서, 동작하지 않으면 전체 시스템이 중단되는 요소)

 

구성 요소

1. 사용자 통합 로그인

2. 인증 서버

3. 통합 에이전트 : 각 정보 시스템에 대한 정보 관리

4. LDAP(Lightweight Directory Access Protocol) : 인사된 사용자만 접근하도록 하는 네트워크 디렉토리 서비스

 

기술 요소

- 인증 : PKI(Public Key Infra structure), 생체 인식, OTP

- 관리 : LDAP, 쿠키

- 암호화 통신 : SSL(Secure Socket Layer), IPSec(IP Security Protocol)

 

SSO의 구현 모델

인증 대행 모델(Delegation)

Delegation model

- 사용자 인증 방법을 별도의 SSO Agent가 대행하는 방식

- 인증 방식을 변경하기 어려울 때 주로 사용

인증 정보 전달 모델(Propagation)

Propagation model

- 사용자를 인증한 사실을 전달받아 SSO를 구현하는 방식

- 통합 인증을 수행하는 곳에서 인증 > 토큰 발급 > 대상 앱에 사용자가 접근할 때 토큰을 자동으로 전달

- 웹에서는 쿠키를 이용해 대부분 이 모델을 채택

 

Delegation & Propagation 모델

- 웹 변경 X & 사용자 통합 어려울 때 Delegation 방식 사용

- 각 앱은 Delegation 방식과 Propagation 방식을 혼용하여 전체 시스템의 SSO를 구성

One Cookie Domain

- SSO 대상 서비스와 응용 앱이 하나의 Cookie Domain에 있을 때 사용

- 일반적인 기업 내부의 컴퓨팅 환경에서 사용

- Web을 기반으로 함

- SSO 에이전트는 토큰으로 사용자 확인, 접근 허가

Bulti Cookie Domain

- SSO 대상 서비스와 응용 앱이 여러 도메인으로 분산되었을 때 사용

- 사용자 인증 및 토큰 발행을 위한 마스터 에이전트가 존재

- 서비스 에이전트는 그 토큰을 자신의 Domain에서 Cookie로 저장해 사용할 수 있게 함

기반에 따른 SSO 보안 기술

Client-Based

- Password Plus와 같은 비밀번호 관리 도구 이용

- 사용자는 자체 시스템에 ID,PW를 기억 , PC에서 자동으로 입력하게 함

- 사용자가 설치,사용 > 편리

- 새로운 앱이나 사이트에 추가될 때마다 정보가 갱신되어야하는 문제점.

- 비밀번호 조합에 업계 표준 X > 보안 문제 발생 가능

Server-Based

- 중앙 서버에서 모든 비밀번호를 관리

- 사용자가 업데이트 X, 다양한 PC에서 접근 가능

- Admin은 비밀번호의 수준 관리

- 사용자와 서버 사이에 존재하는 전반적인 인프라까지 처리

- 업계 표준 X

- 서버의 가용성 보장되어야 함

Service-Based

- Microsoft account는 중앙집중 서버, 쿠키, 표준화된 구조를 이용

- 사용자는 한 번 Microsoft에 접속 > 여러 웹에 접속할 때 그 인증이 유지됨

- 특정 서비스의 제공업자와 제휴되면 편함

- 더 심화된 고객 프로필로 연결 > 기업들의 참여 유도

- 개인정보 보호와 관련된 문제 제기 가능

Token을 활용한 SSO의 구현

Token

- 최초 인증을 성공한 사용자에게 인증 서버가 발급하는 정보

- Session과 다르게 서버는 로그인한 사용자의 세션을 보관 X

- 클라이언트는 추후 Request부터 해당 토큰을 포함해야함

- 서버는 그 Request의 토큰을 그때그때 확인하여 인증과정을 거침

Token 발급 방식의 SSO 구현 다이어그램

1. 사용자가 Service 1에 접속 > 로그인 버튼 클릭

2. Service 1은 인증서비스(idP)로 해당 요청을 Redirect

3. 인증 서비스는 User에게 로그인 화면 제공

4. 사용자는 ID,PW / OAUTH2.0을 입력

5. 인증 서비스는 회원 DB와 비교 > 올바르면 인증 토큰 발급 > 다시 Service1으로 돌려보냄

6. Service 1은 발급된 토큰 확인 > 올바르면 로그인 처리 진행

7. 사용자가 Service 2에 접속

8. Service 2(service 1의 하위 서비스)는 이 User의 세션이 유효한 지 확인 > 유효하면 Service 2용도의 토큰 발급

9. Service 1은 발급된 토큰 확인 > 올바르면 사용자의 로그인 처리 진행

 

- 서버는 세션 정보를 보관 > 그 기간동안 재접속한 사용자를 지원

- 만약 유효 기간이 만료된 사용자가 재로그인하는 건 불편하므로 다음과 같은 방법으로 보완

- Youtube, FaceBook등이 이와 같은 방법을 사용함

 

1. 인증 서버는 ID,PW를 DB에서 확인 > 정상 로그인 > Access Token, Refresh Token 발행

2. Access Token이 만료 > Refresh Token으로 인증 서버에게 Access Token 재요청

3. Refresh Token은 인증 서버의 세션 정보 포함

4. 인증 서버는 Refresh Token과 세션 정보를 비교 > Access Token 재발급

5. Refresh Token 마저 유효 기간이 지나면 User는 다시 로그인 해야함

 

- Access Token은 유효기간이 짧고, Refresh Token은 유효기간이 상대적으로 긺

인증 토큰의 내용 및 유효성 검사 방법

JWT

: JSON Web Token

- 여러 토큰 중 JWT를 통해 예제를 살펴보겠음

인증 토큰의 내용과 유효성 검사 방법 - JWT

1. 인증 서버(idP)와 각 Service 서버들은 사전에 비밀키(Primary Key) 공유

2. 정상적인 인증(로그인)이 확인 > 인증 서버는 Token에 이메일, 이름, 유효 시간 등을 입력하여 발급

3. Token을 Base64 Encoding 함. 이는 암호화가 아닌 인코딩 > 누구나 확인 가능

4. HTTPS 보안 채널로 토큰 확인 요청. 비밀키가 없는 해커는 Token의 내용 변조 불가능

5. Service 서버는 비밀키로 토큰 변조 여부 확인 > 사용자 정보 확인 후 인증 처리 진행

 

- 가벼운 토큰 사용 > 인증 처리 작업을 하는 서비스들은 부담 X

- Primary Key가 없으면 토큰 변조 X , 보안성 보장

- 해커가 중간자 공격 등으로 토큰 탈취하면, 그 User와 동일하게 보일 수 있다는 보안 취약점 존재

- User-Agent, IP 주소 확인 등 여러 보완책 필요

- Naver는 Access Token이 유효해도 User의 IP 주소가 바뀌면 재 로그인 시킴

 

 

---

참고

https://co-no.tistory.com/entry/%EC%84%9C%EB%B2%84-%EA%B3%B5%ED%86%B5-SSOSingle-Sign-On-%EC%9D%B4%EB%9E%80

[개념] SSO(Single Sign-On) 이란?

 

https://helloworld-88.tistory.com/98

[기본] SSO(Single Sign On) 연동

 

https://brunch.co.kr/@sangjinkang/36

인증 토큰을 활용한 SSO의 구현