SSO (Single Sign On)에 대해서 알아봐요.

서론

이번 포스팅은 자주 이야기 하지만 막상 동작 원리를 물어보면 갸우뚱 하는 경우가 많아 정리 차원에서 포스팅 합니다. SSO가 무엇이며, 어떠한 사용 불편함을 해소하기 위해 도입된 기술이며, 어떻게 적용할 수 있는지에 대해 딱딱한 기술적인 용어를 최대한 배제해보고 이야기 해볼려고 합니다.

SSO가 왜 필요했을까?

결론부터 말하면 “주로 사용하는 ID.Password 정보 1개로 다수의 서비스를 동일하게 사용하고 싶다” 가 정답 입니다. SSO 서비스를 사용하지 않는다고 가정하고, 아래 카카오, 페이스북 그리고 구글 메일 3개 서비스 이용을 가정한다면 각각의 서비스가 요구하는 방식으로 로그인을 요구하고 사용자는 통일하여 1개 또는 개별 3개 정보를 기억 해야 합니다. 기억해야 할 정보가 많은 시대에 각 다른 계정 + 암호로 가입한다면 금방 잊어버릴 확률이 높아 집니다.

위와 같이 개별 서비스에 가입할 때 각각의 ID.Password 정보를 기억 해야 하는 것도 버거운데, 만약 동일 회사에서 서비스하는 각각의 서비스를 이용하기 위해 각각의 인증 정보를 가져야 한다면, 생각만해도 싫은 환경 입니다.

• 사용자 입장에서는 (ID:Password) 정보 세개를 기억해야 합니다.
• 서비스를 제공하는 사업자 입장에서도 로그인 화면 3개, 데이터 베이스 3개, 로그인 프로세스도 3개가 구현되어야 합니다.

물론 DB / 프로세스는 서비스들 끼리 데이터 싱크를 통해 어느정도 해소할 수 있지만, 최근 개인 정보 보안 보호에 대한 다양한 정책들로 이것마저도 쉽지 않은 상태 입니다. 이런 상황이되면 결국은 소비자도 기업도 모두 불편해지는 이상한 환경이 됩니다.

SSO를 이야기 하기 전에 먼저 2가지 용어를 알고 가는게 좋습니다.

• SP – Service Provider: 서비스, 어플리케이션 등 다양하게 호칭하고 있습니다. 간단하게 인증을 거쳐야지만 사용할 수 있는 서비스라고 정의 하시면 됩니다. 하나의 회사가 여러가지 인증이 필요한 서비스를 할 수 있는데, 이것들도 통칭 SP (Service Provider)라고 생각 하시면 됩니다.
• IdP – Identity Provider: SP(Service Provider)를 사용하기 위해 인증을 할 수 있도록 공통 인증 관련 부분만 모아서 구성한 서비스라고 생각 하시면 됩니다. 보통 하나의 회사가 다양한 인증이 필요한 서비스를 이용할 수 있도록 하기 위한 그룹이라고 생각하면되며, 일반적으로 타회사 인증 부분까지 포함하는 IdP 는 없습니다. (큰 회사같은 경우 다양하게 도입하는 모든 시스템을 하나의 IdP로 묶어 인증을 통합하기는 합니다.)

SSO는 어떻게 동작하고 인증을 넘겨 주는가?

이제 기본적으로 알아야 하는 정보는 모두 나열 했습니다. 준비 운동이 끝났으니 어떻게 움직이는지에 대한 엔진 부분을 확인 해보겠습니다. 처음에는 헷갈리고 혼란할 수 있습니다. 하지만 인증 절차와 순서를 5번 정도 따라가보시면 “아 이런거구나” 라고 느낌이 올거에요. SSO 구조는 개발자 뿐만아니라, 최근에는 시스템 엔지니어 에게도 중요한 요소 중에 하나로 자리 잡고 있어 한번 이해 해두시면 두고 두고 사용할 수 있을겁니다. 참고로 아래 예시로 들어드린 구글 서비스가 내부적으로 동일하게 동작한다고 보장할 수 없지만 사람들에게 가장 잘 알려진 서비스로 예를 들어드리면 조금 더 쉽게 다가 갈 수 있을거 같아 예로 들어 드렸습니다. 

여러 서비스가 있지만, 수많은 사람들이 사용하고 있는 대표적인 SP (Service Provider)인 구글 서비스를 이용해 인증 절차에 대해서 그려 보겠습니다.

가장 먼저 접근 하여 사용할 서비스로 지메일을 예로 들겠습니다.

• 사용자가 SP(Service Provider: 지메일)로 접근 합니다.
• 사용자의 인증 세션 정보가 SP(Service Provider)에 존재하지 않기 때문에 사용자 URL을 IdP (구글 통합 로그인 SSO 페이지)로 redirect 시킵니다.
• 사용자의 인증 세션 정보가 IdP에 남아 있지 않기 때문에 (사용자 인증 후, 일정 시간이 지나면 인증 정보가 보안 상 삭제 됩니다.) 사용자는 IdP에서 인증 정보를 입력하고 인증을 진행 합니다.
• 인증이 완료되면 IdP는 사용자를 SP (Service Provider)로 rediret 시키며, 이때 동시에 사용자의 인증 정보를 SP (Service Provider)로 전달하여, 인증을 진행 합니다.
• 로그인 정보사 정상적이라면, 인증에 성공하며, 이 후 지메일을 사용할 수 있습니다.

여기까지 지메일에 한번도 로그인 하지 않아 인증 세션 정보가 없을 때, 진행한 SSO 연결 절차 입니다. 그렇다면 이렇게 인증 성공 후 다시 구글 서비스 중 하나인 구굴 포토 서비스를 사용하고자 한다면 어떤 인증 절차를 거칠까요? 위와 같이 처음 인증 절차를 거치는 순서를 거칠까요? 아니면 조금 더 간단한 인증 절차를 거칠까요? (아래 순서를 확인 해보시기 바랍니다.)

• 사용자가 구굴 포토 (Service Provider)를 사용하기 위해 서비스에 접근 합니다.
• 사용자의 로그인 세션 정보가 SP (Service Provider)인 구글 포토에 존재하지 않기 때문에, IdP로 redirect 시킵니다.
• 어라? 조금 전 구글 지메일를 사용하기 위해 사용했던 인증 세션 정보가 남아 있네요? IdP 서비스는 사용자에게 인증 요청을 redirect 시키지 않고 남아 있는 인증 정보를 가지고 SP (Service Provider) 구글 포토 서비스로 redirect 시키면서 동시에 사용자 인증 세션 정보를 가져와 인증을 진행 합니다.
• 사용자는 지메일을 사용하기 위해 인증한 인증정보를 추가로 입력하지 않고 IdP에 남아 있는 인증 세션 정보를 이용해 background 인증을 진행하여, 사용자의 인증 입력 없이 인증 절차를 끝마쳐, 사용자는 곧바로 구글 포토 서비스를 인증 없이 사용 합니다.

SSO를 구현할 때 가장 중요한게 뭘까요?

개인적인 생각으로 사용자 <-> SP <-> IdP 사이에 오고가는 사용자 인증 정보와 IdP에 저장되어 있는 사용자 인증 정보의 보안 이라고 생각 합니다. 다행히 MS / Google 등 대형 IT 기업에서는 이런 서비스를 표준 프레임워크 기반의 서비스를 제공 하고 있습니다. 대표적인게 SAML, OAuth, JWT 등이 있습니다. 보다 자세한 기술적 부분은 링크 페이지를 참조 해주시면 됩니다.

References

• https://www.youtube.com/watch?v=i8wFExDSZv0
• https://en.wikipedia.org/wiki/Single_sign-on
• https://auth0.com/blog/what-is-and-how-does-single-sign-on-work/

SSO 관련 설정을 할 때마다, 두리뭉실하게 설명하고, 구체적인 프로세스 등을 혼란스러워 하는 주변 분들을 위해 (물론 Self study 겸사 겸사) 정리 하였으며, 최근 MS Office365 SSO 연동을 위해 SAML 서비스를 자주 사용하고 있어 언젠가 한번은 정리 해야지 하는 생각을 가지고 있었지만, 시간이 없다는 핑계로 정리가 늦었네요. 혹시 설명한 내용 중 잘못된 내용이 있다면, 댓글 남겨 주시면 수정 하겠습니다.

감사합니다.

행복곰