SSO(Single Sign-On)
기획 시리즈: Web Authentication
- Cookie & Session & JWT
- OAuth
- OpenID Connect(OIDC)
- SSO 👈
- SAML
이 글은 SSO를 공부하면서 개인적으로 정리한 글입니다. 지적과 조언은 언제나 환영입니다 ㅎㅎ
SSO(Single Sign-On)은 한번의 로그인으로 여러 사이트에 대한 인증을 한번에 수행하여 다른 사이트들을 이용할 때 추가적인 로그인 없이 사용할 수 있는 방법을 말한다.
SSO의 대표적인 사례는 Google 로그인으로 한번의 로그인으로, Gmail, YouTube, Google Calendar 등의 서비스를 로그인 없이 바로 사용할 수 있다! 😁
보통 “통합 인증”을 SSO라고 이르며, 하나의 시스템에서 통합 인증으로 로그인을 했다면, 다른 시스템을 이용할 때 인증 정보 유무를 확인해 있으면 그것으로 로그인을 처리하고, 없다면 다시 통합 인증으로 로그인 하도록 운영된다.
장점.
- 사용자 이름과 암호의 난립을 차단함으로써 사용자 경험(UX) 개선
- 사용하는 이름과 암호의 수를 줄여 암호 위생 상태를 개선하여 보안성을 향상시킨다.
(즉, 쉬운 암호를 여러 곳에서 사용하는 것이 아니라 SSO로 하나의 로그인을 사용하되 그 SSO의 암호는 복잡한 것을 사용한다는 말이다!) - 확장성
- 인증에 대한 부분을 중앙에서 관리함으로써, 인적 자원을 절약
SSO는 크게 두 가지 모델로 나누어 진다.
1. Delegation Model; 인증 대행 모델
Image from here
각 개별 서비스의 인증을 통합 인증을 통해 접근. 본인이 재학 중인 POSTECH SSO가 위와 같은 방식으로 동작한다.
2. Propagation Model; 인증 정보 전달 모델
Image from here
SSO 통합 인증에 로그인 했을 때, “인증 토큰”을 발급 받음. “인증 토큰”으로 개별 서비스에서 인증을 수행함. Google 로그인이 이것에 해당함.
만약 Cookie로 인증 토큰을 구현한다면, 아래의 조건을 충족해야 한다.
- Data Confidentiality; 데이터 기밀 유지: 토큰은 적절한 암호 알고리즘을 암호화 되어야 한다.
- Data Integrity; 데이터 무결성: 토큰은 MAC(메시지 인증 코드) 등을 포함해 데이터의 무결성을 보장해야 한다.
- 토큰에 접근할 수 있는 주소를 제한하거나 유효 시간을 설정해야 한다.