Single Sign on
Single Sign on(SSO, 통합인증)은 여러 자원을 사용하기 위해 한 번의 인증 과정을 거치는 방법으로 편의성을 높여주는 인증 기능입니다.
한 번의 인증을 통해 여러 시스템을 각각 인증하는 과정을 없애 편리하고, 한 사용자의 정보를 여러 시스템에서 함께 연동할 수 있습니다.
최초로 인증을 한 후, 다른 시스템에서 인증 정보를 확인한 후 접근을 허가합니다.
구체적으로 인증은 토큰을 통해 이루어집니다.
한 번의 인증을 수행하게 해주는 ID 공급업체와 여러 서비스들은 토큰을 통해 인증을 확인합니다.
여기서 몇가지 존재를 정리해 보자면 다음과 같습니다.
- 서비스와 ID 공급업체
- 유저와 ID 공급업체
- 유저와 서비스
서비스와 ID 공급업체
웨이브 로그인 페이지의 일부 화면입니다. 기존에 카카오, 네이버, 페이스북 등의 회원이라면 웨이브의 서비스를 이용할 수 있습니다.
여기서 웨이브는 서비스이고 카카오, 네이버, 페이스북 등은 ID 공급업체입니다.
그렇다면 ID 공급업체에서 어떻게 서비스를 신뢰하고 인증 정보를 전달할까요?
서비스와 ID 공급업체는 디지털 인증서와 메타데이터를 교환해 신뢰 관계를 설정하고, SAML(Security Assertion Markup Language), 오스(OAuth) 또는 오픈ID(OpenID)와 같은 공개 표준을 통해 상호 통신합니다.
유저
유저가 서비스를 이용하고자 할 때, ID 공급업체로부터의 인증을 받아야 합니다.
최근 인증을 받은 상태라면 ID 공급업체에서 받았던 토큰을 통해 서비스에 인증이 가능하지만 토큰이 만료 되었거나 없는 상태라면 ID 공급업체로부터 인증을 받아 서비스의 인증을 시도해야 합니다.
- ID 공급업체에 인증 - 서비스 공급업체로 토큰을 발부해 인증 사실을 알림
- 서비스 공급업체에서 해당 토큰의 유효성 여부 검증
- 서비스 공급업체에 대한 접근 권한 부여
다음과 같은 루트로 유저는 서비스를 이용하게 됩니다.
즉, 네이버에 로그인 후, 웨이브를 네이버로 로그인 한다면 토큰을 통해 웨이브 인증이 가능합니다.
SSO 이점과 이면
SSO를 사용하므로서 사내 다양한 서비스에 대한 사원의 계정 정보와 보안 수준을 통합 관리할 수 있습니다.
시스템 관리자가 더 이상 모든 직원의 서비스 액세스를 관리할 필요가 없으며 인적 오류 요소가 줄어들고 IT 부서는 시간을 확보해 더 중요한 작업에 집중할 수 있게 됩니다.
사용 뿐 아니라 보안 수준에서의 이점을 보았을 때, 이중 요소 인증과 함께 사용할 경우 보안 강화를 보장할 수 있습니다.
하지만 SSO를 구현하는 비용과 통제, 표준화, 취약점 등의 과제가 따르게 되기 때문에 도입에 신중해야 합니다. 기존 서비스에 도입할 경우 호환성 문제 또한 이슈가 될 수 있음을 간과해선 안 됩니다.
올해 초에는 SAML 오픈 프로토콜의 검증 버그로 인해 공격자가 공격 대상을 가장해 사이트 또는 서비스에 로그인할 수 있는 상황이 발생했다. 또한 연구원들은 OAuth 취약점이 공격자가 피해자의 모바일 앱 계정에 로그인해서 계정을 장악하는 결과를 초래할 수 있다는 사실도 발견했다.
참고
- 애플리케이션에 어떤 방법으로 SSO를 적용할까
- https://www.itworld.co.kr/howto/193849
- https://www.itworld.co.kr/news/110111
감사합니다.
Text by Chaelin. Photographs by Chaelin, Unsplash.