배경
동아리 해커톤 이후 사이드 프로젝트로 동아리 위키 페이지 개발을 시작하게 되었다.
동아리 위키는 동아리 내 있었던 일이나 레퍼런스들을 보기 쉽게 정리하는 게 목적이라, 이미 구현되어있는 메인 사이트와 로그인을 연동하고자 했다.
그러나 해당 메인 사이트는 이전 기수의 사이드 프로젝트로 제작한 것이라 유지보수가 쉽게 이루어지기 힘들었고, 따라서 DB를 공유하면서 작업하기 어려웠다(사실 이제 와 생각하니 DB를 공유하는 것이 오히려 불필요하다는 생각도 든다)
뿐만 아니라, 리크루팅 페이지를 만드는 사이드 프로젝트 팀도 있었기 때문에, 앞으로 웹사이트의 덩치가 커질 것을 고려하면 다른 대책이 절실해 보였다.
이런 문제를 해결하기 위해 SSO 도입을 결심했다.
SSO란?
위키백과에 따르면,
SSO는, 한 번의 인증 과정으로 여러 컴퓨터 상의 자원을 이용 가능하게 하는 인증 기능
간단히 이야기하면, 한번 로그인해서 인증을 하면, 다른 웹사이트에서 귀찮게 계속 로그인하지 않아도 되도록 해주는 기술이다.
중앙대학교의 포털 로그인 URL을 통해서도 이를 엿볼 수 있다
URL이 https://mportal.cau.ac.kr/common/auth/SSOlogin.do?redirectUrl=https%3A%2F%2Fmportal.cau.ac.kr%2Fmain.do 인 것을 유심히 보자.
mportal.cau.ac.kr에서 로그인을 시도하자 SSO를 호출하고, 파라미터로 redirect할 URI를 넘기는 것을 알 수 있다.
우리가 잘 신경쓰지 않아서 그렇지, 우리 주변에 SSO가 적용되는 부분은 생각보다 많다.
SSO의 종류
조사를 위해 알아본 바에 따르면, 두 가지 모델이 있다.
Delegation 모델과 Propagation 모델이 그것이다.
SSO Delegation Model
Delegation 모델은 구성도를 통해 볼 수 있듯, 별도의 통합 로그인 에이전트를 두고, 에이전트가 사용자의 아이디와 패스워드를 가지고 있다가, 사용자가 서비스에 접속을 시도할 때 대신 로그인해주는 방식이다.. 보통 인증 대상 사이트의 인증 방식이 변경하기 어려운 경우에 많이 사용된다고 알려져 있다.
앞서 언급했듯, 기존 메인 사이트를 변경하는 것은 쉽지 않은 일이였기 때문에 처음에는 이 방식을 고려하게 되었다.
SSO Propagation Model
Propagation 모델이 가장 많이 쓰이는 모델이라고 한다. 인증 서비스가 로그인을 받고 토큰을 발급해, 사용자에게 토큰을 반환하고, 사용자는 이 토큰을 통해 각 웹서비스에 접근하는 방식이다.
Reference and Image source
Reference
채택한 모델
결국 Propagation 모델을 선택하게 되었다.
기존 코드에 대한 수정을 많이 하지 않아도 된다는 점에서 Delegation 모델이 유효했던 것은 사실이지만 (이후 게시물에서 설명할) Cookie 사용으로 인해 어차피 메인사이트 수정이 불가피했던 점, Delegation 모델 특성상 프런트엔드 페이지가 필요했던 점, 레퍼런스의 수 등을 고려하여 Propagation 모델이 프로젝트에 SSO를 도입하는 것에 더 적합할 것이라는 판단을 하게 되었다.
하지만 아직 해결되지 않은 문제가 남았다.
여러 사이트 간 데이터를 공유하기 위해 하나의 JWT 토큰을 둘 것인데, 이걸 사이트 간 어떻게 공유해야 할까?
다음 게시물에서 언급할 예정이다!
