가장 직관적으로 이해하기 쉬운 예로 구글의 서비스를 들 수 있다. 구글 같은 경우는 구글 아이디 하나로 구글의 여러 서비스(구글 드라이브, Gmail, Google 포토 등)들을 이용할 수 있다.
SSO의 장단점
장점 - ID 및 PW의 개별 관리의 위험성 해소 => 중앙집중 관리를 통한 효율적 관리 가능 => 운용비용 감소 서비스별로 ID 및 PW를 달리 하여 각 서버별로 관리하게 되면, 각각의 서버에 보안 솔루션이 각각 적용되어야 하므로, 관리하기가 까다롭고 신경써야 할 것이 많아지게 된다. - User(사용자)의 편의성 증가 Admin뿐만 아니라, User 역시 한 ID 및 PW만 기억하고, 한 번의 인증으로 여러 서비스를 이용할 수 있기 때문에 번거로움이 크게 줄어든다.
단점 - SSO 서버 자체가 단일실패지점(SPoF) ID 및 PW가 노출 시에 전체 시스템이 위험해지며, 이는 SSO 서버 침해의 경우도 마찬가지로 모든 서버의 보안 침해가 가능 해진다. - 각각의 사이트마다 보안 수준이 다르면, 보안에 문제가 생길 수 있다.
SSO의 구현 모델
인증 대행(Delegation) 모델 SSO Delegation (인증 대행) Model / 출처 : https://helloworld-88.tistory.com/98 - SSO 대상 어플리케이션에서 사용되는 사용자 인증방법을 별도의 SSO Agent가 대행해주는 방식 - 대상 어플리케이션의 인증 방식을 변경하기 어려울 때 많이 사용되는 방식 - 동작 방식) User 1이 Target Server 1에 로그온할 때 ID, PW가 필요하다면, Agent는 이 정보를 가지고 있으며, Target Server 1에 User 1이 접근할 때 Agent가 User 1을 대신하여 ID,PW 정보를 전달하여 로그온을 대행함.
인증정보 전달(Propagation) 모델 SSO Propagation (인증정보 전달) Model / 출처 : https://helloworld-88.tistory.com/98
- SSO 시스템과 신뢰관계를 토대로 사용자를 인증한 사실을 전달받아 SSO를 구현하는 방식 - SSO Propagtion은 통합 인증을 수행하는 곳에서 인증을 받아, 대상 어플리케이션으로 전달할 토큰(Token)을 발급 받고, 대상 어플리케이션에 사용자가 접근할 때 토큰을 자동으로 전달하여 대상 어플리케이션이 사용자를 확인할 수 있도록 하는 방식 - 웹 환경에서는 쿠키(Cookie)라는 기술을 이용하여 토큰을 자동으로 대상 어플리케이션에 전달 가능 - 웹 환경에서의 SSO는 대부분 이 모델을 채택하고 있음
Delegation & Propagation 모델 - 웹 환경이라고 하더라도, Propagation 방식이 모두 적용될 수는 없으며, 특히 웹 어플리케이션의 변경이 전혀 불가능하고 사용자 통합이 어려운 경우에는 Delegation 방식을 사용해야 함 - 대상 어플리케이션들이 많이 있고, 어플리케이션의 특성들이 다양한 경우, 각 어플리케이션에 Delegation 방식과 Propagation 방식을 혼용해서 전체 시스템의 SSO를 구성하는 방식
(Web 기반) One Cookie Domain SSO - SSO 대상 서비스와 응용 어플리케이션들이 하나의 Cookie Domain 안에 존재할 때 사용되는 일반적인 기업 내부의 컴퓨팅 환경에서 사용 - 통합 인증을 받은 사용자는 토큰을 발급 받으며, 이 토큰은 Cookie Domain에 Cookie로 설정되어 Cookie Domain 내의 다른 서비스로 접근할 때 자동으로 토큰을 서비스에 제공 => 서비스에서 동작되는 SSO 에이전트는 토큰으로부터 사용자 신원을 확인하고 요청된 자원에 대한 접근을 허가
(Web 기반) Multi Cookie Domain SSO - SSO 대상 서비스와 응용 어플리케이션들이 여러 도메인으로 분산되어 있는 경우 - Multi Domain 환경의 경우, 사용자 인증 및 토큰 발행을 위한 마스터 에이전트가 존재 - 마스터 에이전트는 각 서비스 에이전트의 사용자 인증을 위임 받아 수행하며, 인증된 사용자에게는 토큰을 발급하고 각 서비스 에이전트에게 안전하게 전달 - 서비스 에이전트가 해당 토큰을 자신의 Domain에서 Cookie로 저장하여 사용할 수 있도록 함 - 각 서비스 에이전트의 신뢰도 및 SSO 시스템의 보안 레벨에 따라 다음과 같이 두 가지 방식으로 서비스될 수 있음 ① One Token for All Multi Cookie Domain ② Token for Each Cookie Domain & One Token for Master Agent
기반에 따른 SSO 보안 기술의 특징
Client-Based - 'Vince Sorensensn' 사의 쉐어웨어인 'Password Plus' 와 같은 비밀번호 관리 도구를 이용하면 사용자는 자체 시스템에 수많은 ID 및 PW를 기억시키고 PC에서 자동으로 입력하게 할 수 있음 - 위 과정은 사용자가 설치하고 사용하기에 비교적 편리한 장점. - 새로운 어플리케이션이나 사이트 또는 커뮤니티가 추가될 때마다 정보가 갱신되어야 하는 문제점이 존재 - 비밀번호 조합에 업계 표준이 없으므로 이에 따른 보안 문제가 발생할 수 있음
Server-Based - 중앙 서버에서 각기 다른 모든 비밀번호를 관리할 수 있는 형태 - 사용자는 업데이트와 관련한 번거로운 작업(직무가 변하면 새로운 권한을 인증 받는 등)을 하지 않아도 되며, 다양한 PC에서 접근할 수 있는 장점 - Admin은 비밀번호의 수준(사소한 비밀번호 삭제, 비밀번호 주기적 갱신, 필요시 접속 중단 등)을 관리할 수 있으며, 사용자가 여행 중이거나 다른 PC를 사용할 때에도 사용자가 편리하게 이용할 수 있는 장점 - 클라이언트 시스템에 대한 보안 및 관리 문제뿐 아니라, 사용자와 서버 사이에 존재하는 전반적인 인프라까지 처리해야 한다는 것이 제약이라고 할 수 있으며, 현재 업계 표준이 없기 때문에 더 복잡한 문제점이 존재 - 사용자가 온라인에서 하는 모든 활동이 서버를 통하기 때문에, 서버가 항상 사용될 수 있도록 가용성이 보장되어야 함
Service-Based - 비밀번호를 하나의 서비스로 제공할 수 있는 형태 - 'Microsoft Passport' 는 기업들의 비밀번호의 번거로움을 처리하기 위해, 중앙집중 서버, 쿠키, 표준화된 구조를 이용하는 형태로 사용자 입장에서는 한번 마이크로소프트 서버에 접속하면, 여러 웹사이트에 접속하거나 거래할 때 그 인증이 유지되는 형태 - 서비스 기반은 수많은 사이트들의 특정 서비스의 제공업자와 제휴된 경우, 사용자에게 편리 - 다양한 사이트에서 일어나는 사용자들의 활동을 포착할 수 있어, 더 심화된 고객 프로필로 연결될 수 있다는 점이 존재하여 기업들의 참여를 유도할 수 있는 장점이 존재 - 위와 같은 기업측의 이점이 개인정보 보호와 관련된 문제 발생 소지가 존재하여 현재 사회적 문제로 대두되고 있음
인증 토큰(Token)을 활용한 SSO의 구현
토큰(Token) : 최초 인증을 성공한 사용자에게 일종의 증표로서 인증 서버가 발급하는 정보
- Session(세션) 방식과 다르게 서버가 각각 로그인한 사용자의 세션 정보를 따로 보관하지 않음 - 한 번 인증 토큰이 클라이언트에게 발급되면, 클라이언트는 추후 Request 부터는 해당 토큰을 포함하며, 서버는 클라이언트 Request 에 포함된 토큰을 그때그때 확인하여 인증과정을 거침
토큰 발급 방식의 SSO 구현 다이어그램 / 출처: https://brunch.co.kr/@sangjinkang/36
사용자가 Service 1 에 접속하여 로그인 버튼을 클릭
Service 1 은 인증서비스(idP:Identity Provider)로 해당 요청을 Redirect 함
인증 서비스는 사용자에게 로그인 화면을 제공
사용자는 ID,PW (혹은 OAUTH2.0)를 입력
인증 서비스는 회원 DB와 비교하여 ID,PW 가 올바르면 인증 토큰을 발급하며 Serivce 1으로 돌려보냄
Service 1 은 발급된 토큰을 확인하고, 올바른 토큰이라면 사용자의 로그인 처리를 진행
사용자는 Serivce 2에 접속
Serivce 2 (Service 1의 하위 서비스) 는 이 사용자의 세션이 아직 유효한지 확인하고, 유효하다면 Service 2 용도의 토큰을 발급
Serivce 1 은 발급된 토큰을 확인하고, 올바른 토큰이라면 사용자의 로그인 처리를 진행
일반적으로 토큰은 짧은 유효 시간을 갖는 데 비해, 서버에는 세션 정보를 오랫동안 보관하고 그 기간 내에 재접속한 사용자를 지원할 수 있다. 유효 기간이 만료된 토큰 사용자가 다시 로그인하는 것은 사용자를 매우 불편하게 하므로, 다음과 같은 방법을 사용하여 보완한다. (ex. 유튜브, 페이스북 등)
인증 서버는 ID,PW를 DB에서 확인하고, 정상 로그인이면 Acess Token(액세스 토큰) 과 Refresh Token(리프레시 토큰) 을 발행
액세스 토큰에 대한 재요청을 받은 인증 서버는 리프레시 토큰과 세션 정보를 비교 후, 액세스 토큰을 재발급한다.
리프레시 토큰마저 유효 기간이 지나면, 사용자는 다시 ID,PW 를 통해 로그인 해야 한다.
인증 토큰의 내용 및 유효성 검사 방법
"토큰에는 어떤 정보가 있으며, 이를 어떻게 확인할 수 있을까?"
토큰의 종류는 여러 가지가 있는데, 이 중 JWT(JSON Web Token)을 통해 예제를 살펴보자.
인증 토큰의 내용과 유효성 검사 방법 / 출처: https://brunch.co.kr/@sangjinkang/36
인증 서버(idP)와 각 Service 서버들은 사전에 비밀키(Primary Key)를 공유한다.
ID, PW로 정상적인 인증이 확인되면, 인증 서버는 토큰에 이메일, 이름, 유효 시간 등을 입력하여 발급한다.
토큰을 Base64 Encoding 한다. 이는 암호화가 아닌 인코딩이기 때문에 내용은 누구나 확인 가능하다.
HTTPS 보안 채널로 토큰 확인을 요청한다. 이 과정에서 토큰이 유실되더라도 인증 서버와 Service 서버들이 공유하고 있는 비밀키가 없는 해커는 토큰의 내용을 변조할 수 없다.
Service 서버는 비밀키로 토큰 변조 여부를 확인하고, 이메일 등의 사용자 정보를 확인 후, 인증 처리를 진행한다.
위 방식을 사용하면, 가벼운 토큰을 사용하여 인증 처리 작업을 하는 서비스들이 부담을 갖지 않는 구조이며, 비밀키 없이는 토큰을 변조하지 못한다는 보안성이 보장되는 장점이 있다.
단점으로는, 해커가 중간자 공격 등으로 토큰을 탈취한 후, 변조하지 않은 채 그대로 사용한다면 로그인한 사용자와 동일하게 보일 수 있다는 보안 취약점이 있다. 그래서 User-Agent 혹은 IP 주소를 확인한다거나, 추가적인 여러가지 보완책이 필요하다. 실 예로, Naver 같은 경우, Access Token이 유효하더라도 사용자의 IP 주소가 바뀌면 다시 로그인을 하도록 하는 것도 이러한 이유 때문이다.
최근댓글