내가 재직중인 피닉스다트에서 현재 두 개의 앱을 운영하고 있다. 하나는 일본을 제외한 모든 국가를 타겟으로 하는 Global 앱. 하나는 일본을 타겟으로 하는 Japan 앱이 있다. 이하 각각 Global, JP라고 하겠다.
다트회사에 걸맞게 7월에 열리는 다트 페스티벌에 사용할 앱을 만들고 있는데 문제가 하나 있었다. 그것은 바로 기존의 피닉스다트 앱을 사용하는 사람들은 자신의 계정의 아이디와 비밀번호를 까먹었을 수도 있기 때문에 기존에 설치되어 있는 피닉스다트 앱으로 로그인을 할 수 있는 기능을 만드는 것이었다.
이 기능의 장점이라고 하면, 사용자는 계정의 아이디와 비밀번호를 모르더라도 설치한 앱에 바로 로그인을 할 수 있다는 점이다. 개발자에게도 장점이 있는데 다른 SNS 로그인 기능을 구현하지 않거나 이후에 구현할 수 있다는 점이다. Global의 경우 Kakao 로그인이, JP의 경우 Line 로그인이 있는데 그 외 구글, 애플, 페이스북 로그인 등을 모두 로그인에 넣는다면 빠듯한 일정에 차질이 생길 수 있다. 그래서 피닉스다트 앱으로 로그인은 1순위, 나머지는 후순위로 구현할 수 있었다.
이를 구현하고 나서 이사님이 하신 말씀은
승원님은 이제 SSO를 구현하신 겁니다."
이게 SSO라고? SSO가 뭐지? 좀 더 자세히 알아봐야겠다는 생각이 들었다.
물론 SSO라는 아이디어와 서버 쪽은 이사님이 고안하셨지만 이때 처음 알게 된 SSO라는 개념이 어떻게 앱에 적용되었는지 정리해보려고 한다.
전체적인 흐름을 이렇다. 사실 해당 방법은 JP에서 로그인할 때 사용된 로직이고 Global에서는 App Group을 이용해서 로그인 정보를 받아오는 식으로 진행하였다. 사실 App Group만을 이용한다면 가장 간단하게 구현할 수 있었지만 Global과 JP의 Apple 개발자 계정이 달라서(?) App Group을 통해 정보를 주고받을 수 없었다.
그러니 만약 다른 앱으로 로그인하는 기능을 만들고 싶다면 App Group을 이용하는 방법도 고민해보자.
누군가는 이런 궁금증을 가질 수도 있을 것이다.(아님 말고~)
서버만 거치면 안돼? 굳이 피닉스다트 앱까지 거칠 필요가 있을까?
이에 대한 답은 간단하다. 사용자는 자신의 아이디, 비밀번호를 모르더라도 로그인을 할 수 있어야하기 때문이다.
SSO(Single Sign-On)는 사용자가 하나의 ID로 서로 관련되어 있지만 독립적인 여러 소프트웨어 시스템에 로그인할 수 있도록 하는 인증 체계입니다. - Wikipedia
구글링하다 보니 정보처리기사에서 다루는 개념이었음
우선 SSO에는 크게 두 가지 유형이 있다.
SSO 에이전트가 인증 정보(id, password)를 보관하고 있다가 해당 시스템으로 전달해주는 방식을 말한다.
보통 권한을 얻으려는 서비스의 인증 방식을 변경하기 어려울 때 사용한다.
Global에서 App Group을 통해 id와 password를 전달해줬는데 피닉스다트 앱이 일종의 SSO 에이전트 역할을 하여 이 방식이 일종의 Delegation 방식이라고 봐도 무방할 것 같다.
통합 인증을 수행하는 곳에서 인증을 받아 인증 토큰을 발급받는다. 발급받은 토큰을 서비스에 전달하면 서비스는 토큰을 통해 사용자를 인식할 수 있게 된다.
JP 앱이 통합 인증을 수행하는 곳이 되고 인증 토큰을 발급받아 PX에 전달해주니 이 방식은 Propagation 방식이라고 보면 될 것 같다.
짧지만 SSO가 어떤 개념인지 큰 그림은 그릴 수 있었다. SSO의 장단점이나 JWT, SAML, oAuth, OIDC 등 다뤄야 할 것들이 정말 많지만 이후에 시리즈로 다루려고 한다.
오늘은 여기까지!!