SSO(Single Sign-On) 통합인증 이란?

서론

현재 일하고 있는 곳에서는 내부망에서 다양한 시스템들을 운영하고 있습니다. 여기서 주목한 점은 한 번의 로그인으로 내부의 모든 시스템을 재 로그인 없이 이용할 수 있는 방식인 SSO(Single Sign On) 인증 방식입니다.
이번 게시글에서는 이러한 SSO(Single Sign On)에 대해서 한번 정리해 보겠습니다.

 

SSO란?

SSO는 Single-Sign-On의 약자로 한 번의 로그인으로 여러 개의 사이트들을 재 로그인 없이 이용하는 방법을 말하며, 통합인증이라고도 부릅니다.

SSO가 아닌 방식

위 이미지는 SSO가 아닌 방식입니다. 일반적으로 위 이미지처럼 서로 다른 시스템은 서로 각각의 사용자 인증 방식이 필요합니다. 카카오톡 로그인을 했다고 해서 페이스북을 추가적인 로그인 없이 이용할 수 없고, 마찬가지로 gmail도 마찬가지입니다.
만약 동일 회사에서 서비스하는 각각의 서비스를 이용하기 위해서 매 서비스마다 인증 정보를 거쳐야 한다면, 서비스를 만드는 입장에서도 추가적인 구현이 들어가야 하고, 사용자 입장에서도 각각의 서비스마다 아이디와 비밀번호를 기억해야 합니다.

SSO 방식

위 이미지는 SSO 방식입니다. google이 대표적인 SSO를 사용하는 예라고 할 수 있는데, 구글 로그인만 하면 gmail, google drive, google photo 등 다양한 서비스들을 추가적인 로그인 없이 이용할 수 있습니다.
그렇다면 이제 SSO를 더 자세히 알기 전에 두 가지 단어에 대해 먼저 알아보겠습니다.

• SP(Service Provider): 서비스, 애플리케이션 등 다양하게 불리고 있으며, 인증을 거쳐야만 사용할 수 있는 서비스를 의미합니다.
• IdP(Identity Provider): SP를 사용하기 위해 인증을 할 수 있도록 공통 인증 관련 부분만 모아서 구성한 서비스입니다. 보통 하나의 회사가 다양한 인증이 필요한 서비스를 이용할 수 있도록 하기 위한 그룹이며, 타 회사 인증 부분까지 포함하는 IdP는 거의 없다고 합니다.

 

SSO의 유형

SSO는 크게 두 가지 유형 1)인증 위임 모델(Delegation)과 2)인증 정보 전달 모델(Propagation)로 나뉩니다.
1) 인증 위임 모델(Delegation)

인증 대행 모델(Delegation)

1. SSO 에이전트가 인증을 대행하는 방식
2. 대상 애플리케이션의 인증 방식을 변경하기 어려울 때 많이 사용
3. 사용자의 인증 정보를 SSO 에이전트가 관리하며 로그인 대신 수행

2) 인증 정보 전달 모델(Propagation)

인증 정보 전달 모델(Propagation)

1. SSO에서 인증을 수행, 토큰을 발급하고 전달하여 인증 수행
2. SSO에서 인증을 받아 대상 애플리케이션으로 전달할 토큰 생성
3. 애플리케이션에서 SSO의 토큰 검증을 인증된 것으로 처리

보통 웹 기반의 방식에서는 2번 방식인 토큰을 전달하는 방법으로 주로 사용합니다.

 

SSO를 구현하기 위한 기술 요소는?

SSO를 구현하려면, 먼저 인증 서버가 있어야 하고, 이를 다양한 서비스들과 어떠한 인증 관련으로 연계할지 설계해야 합니다. 또한 인증 서버에서 인증을 성공적으로 수행했다는 "증거"를 다른 서비스들이 어떻게 받아들일 것인지에 대한 기술적 고민도 필요합니다.
기업 내 솔루션에서 SSO는 전통적으로 모든 사용자(사원)의 인증 정보를 담고 있는 AD(Active Directory)나 LDAP(Lightweight Directory Access Protocol)을 적용한 솔루션들을 많이 사용해왔습니다.
SSO의 직접적인 구현을 위해서는 위에서 언급했던 대로 두 가지의 방법 있지만 저는 SSO의 인증 정보 전달모델(Propagation)의 인증 토큰(authentication token)을 사용한 SSO 방식에 대해 정리해 보겠습니다.
여기서 토큰은 최초 인증이 성공한 사용자에게 일종의 증거로 인증 서버가 발급하는 정보며, 최근에는 RestAPI 방식으로 통신하는 추세 이며 이때 JWT 토큰을 주로 이용합니다.
예전의 웹 개발에서는 로그인에 성공한 사용자는 웹 서버와 Session을 맺고, Session ID 정보를 쿠키로 받아, 그 쿠기를 로그인의 증거로 사용했습니다. 모든 요청마다 헤더에 Session ID 쿠키를 넣고 웹 서버에 접속을 하게 되면, 웹 서버는 서버에 보관되어 있는 Session 정보와 비교하여 유효하게 로그인한 사용자임을 확인하고 콘텐츠를 제공하는 방식이었습니다. 하지만 이 세션 방식의 경우 매번 요청마다 서버가 Session 정보를 확인해야 하는 부담과, 세션 저장소 사용으로 인한 서버 부하가 문제가 되었습니다.(저희 회사는 세션을 사용합니다.)
이에 반해 토큰 방식의 경우는 인증을 위한 별도의 저장소가 필요 없고, 별도의 I/O 작업 없는 빠른 인증처리와 더불어 확장성이 우수합니다. 현재 최신 B2C 기업들은 전부 토큰 인증 방식을 많이 사용하고 있습니다.
위 세션과 토큰의 차이점에 대해 더 자세히 알고 싶으신 분들은 "토큰 vs 세션"이라는 키워드로 서치 하시면 더 상세한 정보를 얻으실 수 있을 겁니다.

 

마무리

사내망 포털의 접속 과정에 대해 살펴보다가 AD와 SSO라는 용어가 나와서 정리하게 되었습니다. 사실 지금까지는 토큰을 이용하면 한 번의 로그인으로 다양한 서비스를 이용할 수 있는 통합인증 방식이 가능하다는 것은 당연한 것이기에 이렇게까지 통합인증을 정의하는 용어를 생각해보려는 시도는 해보지 않았기에 조금 생소하면서도 의미 있는 정리시간이었던 것 같습니다.