OpenID와 단일사용자 로그인(Single sign on)

단일 사용자 로그인(Single Sign On; SSO)은 다음과 같은 상황에서 일어납니다.

1. 사용자 인증
2. 인증을 공유할 같은 도메인 혹은 그 서브 도메인의 서버들
3. 각 서버들은 그 기원이 서로 다른 서비스로 운영됨.
4. 각 서비스들이 요구하는 사용자 정보는 최소한으로 ID 이며, 그 외에 이메일, 이름 등이 있음.

이를 위해서는

1. 가장 공통의 인증을 위한 미들웨어 강제로 사용하는 방법이 있을 수 있고,
2. 웹이라면 쿠키의 서브 도메인에 설정하는 기능을 이용하여, 전달 받은 쿠키를 공유하는 DB 질의를 통해서 접근하는 방법이 있으며
3. 토큰하나를 캐시나 URL에 인코딩하여 전달한 뒤, 토큰의 진의 여부를 결정해주는 내부 서버를 두어 필요시마다 서버들간 대화를 하게 만들 수도 있고,
4. 무식하게는 ID와 패스워드가 몰래몰래 네트웍을 날아다니게 만들 수 도 있습니다.`

OpenID는 하나의 사이트에 로그인할 때, 세 번의 질문을 하게 됩니다. 하나는 OpenID를 묻는 것이고, 두번째는 OpenID 자체의 소유여부를 확인하기 위한 비밀번호 등이고, 세번째는 인증정보를 전달할 도메인을 확인하고자함입니다. 대개 두번째 질문은 한 동안은 묻지 않고 유지 됩니다. 세번째도 만약 신뢰하는 사이트라면 묻지 않게 됩니다.

OpenID가 SSO를 구현하는데 사용된다고 합니다만, 이를 위해서는 로그인사이트(Consumer Site; Relying Party)들이 정교한 처리를 해주어야합니다. 몇몇의 서비스를 이용해 보셨지만, 한 사이트를 사용하다가 다른 사이트에 이동하게 되면, 적어도 셋 중 최초 자신의 OpenID는 넣어야 인증이 됩니다.

정교한 처리란, 이 OpenID 마저 다시 넣지 않는 개발이 필요한 것인데, 만약 그 사이트에 두 번째 들어간다면 처음 로그인할 때 쿠키를 설정해놓고 들어 오자마자 쿠키에 씌여 있는 OpenID로 로그인 시도를 할 수 있겠지요. (Jyte.com이 그런 행위를 하는 것 같습니다만, 때에 따라 그렇지 않은 것을 보아서 정확한 구조는 파악 못하였습니다.)

OpenID가 SSO에 사용된다는 것은, 최초 OpenID를 제출하고, 이것의 OpenID의 소유자임을 확인한 브라우져 세션에 대해 "계속 승인"으로 설정한 경우, OpenID를 제출하는 것만으로 로그인이 가능하다는 것을 의미합니다. 따라서, 최초에 제기한 조건들을 충분히 만족하지 않고, 이러한 가장 큰 이유는 로그인하는 서비스들이 모두 분산되어 있는 상황이기 때문입니다. 애초부터, 같은 조직이 아닌 서비스들을 단일 사용자 로그인을 지원한다는 것 자체는 보안상 상당히 취약한 생각입니다.

다음 글에는 환상을 품을 만한 실험 한 결과를 공유해 보겠습니다.