I'm ALIVE

윈도우 라이브 메신저 웹 툴킷 – 라이브 메신저의 모든 것을 웹에서

지난 글 마지막에서 말씀드린 것처럼 이번 글에서는 윈도우 라이브 메신저 웹 툴킷의 인증 방식에 대해 알아보도록 합니다. 
앞서 소개드렸던 두 개의 쿠키 – msgr-consent-token 과 msgr-delegation-token 기억 나시나요?

뜻 그대로 풀어 보자면 첫 번째 쿠키는 “허용/허가” 라는 뜻을 가진 쿠키이고 두 번째 쿠키는 “위임/대리” 라는 뜻을 가진 쿠키 되겠습니다.
무슨 허용이고, 무슨 위임이지?

이 두 쿠키들이 무엇을 뜻 하는지를 알게 되면 이 의문이 모두 해결됩니다.

기억을 더듬어 우리가 웹 메신저에 로그인 하던 과정을 주의 깊게 살펴 봅니다.

로그인 버튼을 클릭하면 아래 보이는 창이 팝업 됩니다. 이 창에서 붉은 색으로 박스 쳐진 부분을 보시면,
“귀하께서 www.wltoolkit.com 에 방문하시면 자동으로 메신저에 로그인 됩니다. 그게 뭔 말이냐?” 라고 하는 부분을 보실 수 있습니다.

”어라 난 그냥 로그인 하려고 한 것 뿐인데 무슨 자동 로그인?” 하실 분 들 계실 겁니다.
또 “난 이거 했는데도 자동 로그인 안되던데 무슨 소리냐?” 라고 하실 분들 또한 계실 겁니다. 

“그게 뭔 말이냐” 라는 링크 클릭해보시면 설명되어 있는 것과 같이 마이크로소프트 사이트는 아니지만 Windows LiveID 와 연결을 시켜 특정 사이트에 로그인을 하면 자동으로 메신저에도 로그인 할 수 있도록 해 주겠다고 하는 것 입니다.

즉, “내가 이 사이트에 로그인 하면 자동으로 메신저에도 자동 로그인 할 수 있도록 허용해 주겠다” 라고 하는 이야기가 됩니다.

이것을 바로 “consent” 라 합니다.

사용자가 별도로 Windows Live ID에 아이디와 패스워드를 입력하지 않아도 자동으로 윈도우 라이브 아이디 계정을 통해 메신저에 로그인 을 시키겠다라는 이야기가 되는 거죠.

제가 지난 글의 마지막에 읽어 주십사 부탁 드렸던 저의 이전 포스팅 에서 말씀 드렸던 위임인증이 바로 사용된 예가 바로 윈도우 라이브 웹 툴 킷 입니다.
또한 위임했다라고 하는 증거로 필요한 토큰이 위임토큰 – Delegated Token – 이 되는 것 이지요. (앞의 글에서 제가 놀이동산 손목 띠, 클럽의 손목 도장 이야기 했던 것 기억 하시나요?)


정리해 보면

- 허용토큰(Consent Token) - msgr-consent-token 은 자동 로그인을 허용했다는 증거로 받은 토큰.

- 위임토큰(Delegated Token) - msgr-delegation-token 은 나중에 로그인이 필요할 경우 인증 여부를 재 확인 시켜 주기 위해 위임을 받았다는 증거로 제공해야 할 토큰

으로 구분할 수 있습니다.
 
자동으로 사용자를 메신저에 로그인 할 수 있도록 하기 위해서는 허용 토큰(Consent Token)을 웹 사이트의 데이터 베이스에 저장시킨 뒤 사용자가 다음 번 방문 시에 이 두 개의 토큰(Consent Token / Delegated Token) 을 쿠키에 설정해줌으로써 사용자를 대신해서 메신저에 로그인을 시켜주게 되는 것이지요.

이와 같은 방식의 로그인을 허용 토큰을 통한 위임 로그인(Stored Consent Tokens for Delegated Authentication) 이라고 합니다.
사용자는 단 한번의 허용을 마치면 그 뒤로는 별도로 윈도우 라이브에 로그인 하지 않아도 이 허용토큰을 통해 웹 어플리케이션이 사용자의 로그인을 대신해 주게 됩니다.


반면 별도로 허용토큰을 웹 어플리케이션의 데이터베이스에 저장하지 않고 사용자가 직접 Windows Live Messenger 사이트로 부터 발급받은 뒤  웹 브라우저의 life time과 함께 관리하기로 한 경우(one time cookie)에는 브라우저가 닫혀지지 않는 한 로그인이 유지되지만 다음 번 사이트를 방문하게 될 경우에는 허용토큰이 남아 있지 않기 때문에 사용자는 다시 금 로그인 절차를 진행해야 합니다.

이와 같은 방식의 로그인을 어플리케이션 검증토큰을 통한 위임 로그인(Application Verifier Tokens for Delegated Authentication)이라고 합니다. 
 

지금 우리가 앞서 실행해본 방식은 어플리케이션 검증 토큰을 이용한 위임 로그인 방식을 이용한 것이라는 것. 이해 되시겠지요?

사이트와 사이트 사이 서로 연계되어 데이터를 교환하는 요구사항들이 늘고 있는 요즘 위임인증은 상당히 효과적이고 안전한 인증 방식이 됩니다.

위임 인증을 보다 간단히 설명을 하자면,

A 라고 하는 저장소(스카이드라이브/ 페이스북 / 트위터 등등)에 있는 나의 데이터를 B라고 하는 사이트에서 사용하고자 할 때 B 사이트에 A에서 사용되는 아이디와 패스워드를 우리가 넘겨준다면?
해킹의 소지도 있을 뿐만 아니라 왠지 모를 찝찝함이 남을 수 밖에 없죠.
 
[B 라고 하는(Importer)에게 Web Site(저장소)에서 데이터를 가지고 오기 위해 자신의 아이디와 패스워드를 전달하는 예]

하지만 이러한 방식을 그림에서 처럼 바꿔준다면,
 
[위임인증 토큰을 사용하여 Importer는 Web Site에 사용자의 정보를 요청한다]

사용자는 안전하게 Web Site에 저장된 데이터를 Importer에게 별도로 자신의 Credential 정보를 넘겨주지 않고도 사용할 수 있게 되는 것입니다.

지금 보시는 비디오 클립이 잘 설명해 주고 있습니다.
친구를 추가하기 위해서 Windows Live에 MySpace의 Credential 정보를 넘겨주지 않죠.
이것이 바로 위임인증을 사용한 예 입니다.

보다 자세한 위임인증(Delegated Web Auth) 에 대해 알고 싶으시면 소개해 드리는 링크를 꼭 한 번 읽어 보시라 권해 드립니다. - Understanding Windows Live Delegated Authentication

오늘은 윈도우 라이브 메신저 웹 툴킷이 사용하는 내부 인증 메커니즘에 대해 알아 보았습니다.
다음 글에서는 윈도우 라이브 툴 킷의 UI 컨트롤들을 이용하여 간단한 예제를 만들어 볼까 합니다.

Windows Live Service team 의 Angus Logan 씨가 Safter Internet Day에 있었던 OpenID UX summit에서 느꼈던 Ineternet 을 보다 안전한 곳으로 만들기 위한 Microsoft의 솔루션에 대해 기술한 블로그를 소개 합니다.

Making the Internet a safer

Social Network에 대한 관심이 높아져가면서 이와 함께 인터넷 사이트 도처에 흩어져 있는 사용자의 연락처 정보들에 대한 관리가 커다란 관심거리가 되고 있습니다.  

이러한 정보들을 한 곳에 모을 수 있는 솔루션들도 많이 출현하고 있는데 그 중 대표적인 솔루션으로 Octazen(http://octazen.com/product_abi.php) 사의 Contacts Importer(Address Bokk Grabber)를 꼽을 수 있습니다.
* 물론 아쉽게도 국내 포털 사이트의 연락처 데이터를 가지고 오는 기능은 현재 제공하고 있지 않습니다.

사용자가 어플리케이션에 자신의 아이디와 패스워드 정보를 입력하면 이 정보를 바탕으로 자동으로 해당 사이트의 연락처 정보를 가져오는 시나리오가 되겠는데요…..[테스트해보기]

문제는 여기서부터 시작 됩니다. 
솔루션을 개발한 업체를 못 믿어서 하는 이야기는 아닙니다만, 사용자만 알고 있어야 할 정보(아이디/패스워드)를 자신의 연락처 정보를 관리해 준다는 기능을 위해 울며 겨자 먹기로 솔루션 업체 (혹은 어플리케이션)에 알려 준다는 건 어딘가 보안상 불편한 느낌을 지울 수 없게 됩니다.
(그럴 리야 없겠습니다만, 악의적인 관리자에 의해 개인정보는 충분히 악용될 수 있는 소지가 있습니다.)


[내 아이디와 패스워드를 달라고???]

사용자의 정보는 사용자와 인증정보를 관리하는 곳만이 알고 있어야 하는 것이고, 그 이외의 사이트에서는 이에 대해 알 필요도, 관리도 해선 안 된다.
라는 지극히 당연하다라고 생각되지만 현실적으로 그래오지 못했었던 부분을 바로잡고자 하는 시도들이 인터넷 상의 인증프레임워크를 갖추는 일 입니다.

지난해 대형 온라인 경매사이트의 개인정보 유출 사건을 되돌아 보면 왜 인터넷상의 인증 프레임워크(서비스)가 필요한 것인지를 충분히 느끼실 수 있을 것입니다.

Microsoft의 LiveID(Delegated Web Authentication) 와 OpenID/oAuth 가 바로 이러한 문제들을 해결하기 위한 시도들 입니다.

Microsoft의 LiveID는 서비스는 Microsoft platform은 물론이고 Ruby, Phyton, Java, PHP, Perl 등과 같은 멀티 플랫폼을 지원하며 조만간 정식으로 OpenID까지 지원하는(참조 - Windows Live ID Commits to Support OpenID http://winliveid.spaces.live.com/blog/cns!AEE1BB0D86E23AAC!1745.entry) 가장 앞선 인터넷 기반의 인증 서비스를 제공합니다.
(Windows Azure Service Platform을 사용하기 위한 기본 인증 서비스이기도 합니다.)

인증을 위한 요청 흐름은 다음과 같이 정리될 수 있습니다.(여기서 데이터를 요청하는 어플리케이션을 – Application Provider(어플리케이션 프로바이더)/ 데이터를 제공하는 웹 사이트를 – Resource Provider(리소스 프로바이더)라고 합니다)

먼저 사용자는 특정 어플리케이션(어플리케이션 프로바이더)이 자신의 정보를 웹 사이트를 통해 얻어갈 수 있도록 허용하겠다고 허가를 하면, 인증프레임워크(서비스)는 어플리케이션(어플리케이션 프로바이더)에 인증토큰을 발급해 주고, 어플리케이션(어플리케이션 프로바이더)은 이 인증토큰을 사용하여 웹 사이트(리소스 프로바이더)에 사용자의 정보를 요청하는 순서가 됩니다.

[데이터를 가지고 올 Resource Provider 를 고르자]

[Windows LiveID 를 통한 인증]

[사용자는 Application Provider가 자신의 데이터에 접근할 수 있는 권한(Read,Write/ReadOnly/WriteOnly) 및 접근할 수 있는 기간을 지정함 – 인증토큰 발급]

[인증 토큰을 바탕으로 Application Provider가 가지고 온 Resource Provider의 데이터]

이 경우 실제 사용자의 아이디와 패스워드 정보는 인증 프레임워크(서비스)와 사용자 이외에는 전혀 알 필요도 없고, 관리할 필요도 없습니다.
인증 서비스를 제외한 어느 곳에도 사용자의 정보는 저장되지 않기 때문에 당연히 인터넷의 보안성 또한 높아질 수 밖에 없죠.

인터넷을 통한 네티즌들의 활동이 증가되어 감에 따라 온라인을 통해 생산되는 사용자 데이터는 단순히 연락처 정보를 넘어 사진을 포함한 멀티미디어 데이터, 메일, 어플리케이션 데이터 등 그 동안 일상 생활 속에서 우리가 PC환경에서 생산해 내던 데이터들과 그 양과 종류에서 차이가 없어지고 있습니다.

이렇게 될 수록 인터넷 여기저기 산재된 사용자의 데이터를 조직화 할 수 있는 기능 – Data Portability – 의 요구사항들이 늘어가게 됩니다. 이를 충족 시키기 위해 반드시 고려되어야 할 부분 역시 인증프레임워크(서비스)의 도입이 될 것입니다.

현재 국내의 주요 포털(N사, D사..등등..)들이 경쟁적으로 OpenAPI 를 발표하고 있음에도 불구하고 아쉽게도 아직까지 그러한 API들 중에서 사용자 중심적인 데이터를 제공하는 서비스가 없는 것도 사실은 내부적으로 이러한 인증 프레임워크 도입을 고려하고 있지 않음에 기인하고 있다고 이야기 해도 과언이 아닙니다. (최근에 D사에서는 OpenID 기반의 인증시스템 개발을 진행 중에 있다는 반가운 소식을 들었습니다.)

보다 안전한 인터넷 환경을 만들기 위한 노력. 이제는 선택이 아니라 필수인 시대가 도래했습니다.

자세한 Microsoft의 Data Portability에 관심이 있으신 분은 Windows Live Contacts API 를 살펴보시길 권장합니다.

다음 기회에는 Windows Azure Serive Platform 과 LiveID(인증프레임워크 서비스)와의 관계에 대해 정리해 보는 시간을 갖도록 하겠습니다.