Korean Identity Management(KIM)

기존의 매쉬업 서비스를 살펴보면, 가령 B사이트의 매쉬업 서비스가 A사이트에 저장된 사용자 데이터를 요구할 경우, 사용자는 A사이트에서 제공하는 오픈API를 사용하기 위해 APP Key를 하나 발급받습니다. 이 APP Key를 B사이트의 매쉬업 서비스에 세팅하여 서비스를 이용하게 되는 것이죠. 또는 A사이트의 사용자 id와 password를 직접 저장하기도 합니다. 하지만 이런 방식은 A 사이트에 대한 모든 권한을 B 사이트에게 넘겨주는 것입니다. B 사이트가 해킹당하거나 혹은 악의적인 의도를 가진 내부자가 있다면, A 사이트에 저장된 사용자의 정보를 무단으로 이용하고, 사용자의 계정으로 스팸 메일을 뿌리거나 악플을 달수도 있습니다. 이렇게 매쉬업 서비스를 위해 사용자의 모든 권한을 넘겨주는 문제를 API Key 문제라고 부릅니다.

OAuth는 한 어플리케이션이 다른 어플리케이션에서 관리하는 사용자 정보를 접근할 수 있는 표준화된 방법을 제공하는 스펙입니다. 이 스펙은 매쉬업 서비스의 API Key 문제를 해결하기 위해서 제시되었습니다. OAuth는 사용자가 허락하는 수준의 권한만을 타 서비스에 제공하는 방식을 제공합니다. 아래 문장이 OAuth의 장점을 명쾌하게 설명하고 있죠.

OAuth는 당신이 사용하는 모든 웹서비스에 대한 발렛 키다. 발렛 키는 당신의 차를 주차할 수 있을 정도의 권한만 제공하지, 트렁크를 열거나 2마일 이상 운전하거나 RPM의 빨간 선까지 속도를 내는 권한은 없다. 마찬가지로, OAuth 키는 웹 에이전트가 당신의 웹 메일을 체크하는 기능만 제공하며, 당신인 것처럼 해서 주소록에 있는 모든 사람에게 메일을 보내는 일은 하지 못하게 한다.
- http://journals.aol.com/panzerjohn/abstractioneer/entries/2007/09/21/oauth-your-valet-key-for-the-web/1550

OAuth는 10월 3일자로 최종 드래프트 스펙  이 공개되었습니다. 기술적인 내용을 원하시면 스펙을 보시는 게 낫지만, 쉬운 설명을 원하신다면 primer  를 보시길 바랍니다.

아래 그림은 OAuth 스펙에 명시된 인증 절차입니다.Consumer는 매쉬업 서비스를 제공하는 사이트이고 Service Provider는 사용자 정보를 보유한 사이트입니다. Consumer가 Service Provider로부터 Request Token을 발급받은 후, 사용자의 동의를 거쳐서 Access Token으로 교환하고, 이 Access Token으로 사용자 데이터에 접근하는 순서로 이루어집니다. 각 스텝별로 간단히 설명드리겠습니다.

1. A; Consumer가 Request Token 요청
2. B; Service Provider가 Request Token 발급
3. C; Consumer는 사용자를 Service Provider로 이동, 사용자를 인증하고 토큰 발급을 확인함
4. D; Service Provider는 사용자를 Consumer로 이동
5. E; Consumer는 Access Token 요청 
6. F; Service Provider는 Consumer의 신원과 Request Token 확인, Access Token 발급
7. G; Consumer는 Access Token으로 사용자 정보에 접근

출처: http://oauth.net/documentation/spec

OAuth의 동작 방식은 생각보다 간단합니다. OpenID의 동작 방식과도 유사하죠. Google AuthSub, AOL OpenAuth, Yahoo BBAuth, Upcoming API, Flickr API, Amazon Web Services API 와 같은 유사 API가 이미 있습니다. 하지만 이들 방식은 모두 독자적이지만, OAuth는 공개 스펙입니다. 개별적인 접근 요청을 사용자가 직접 제어할 수 있으며, 해당 목적에 필요한 권한만을 선택적으로 제공할 수도 있습니다. 매번 사용자의 허락을 받지 않아도 되며 UI(User Inferface)나 인터렉션 패턴이 없다는 점을 강조합니다.

하지만 실제로 스펙을 살펴보면 사용자가 관여하는 부분이 명시적으로 존재하기 때문에, UI와 인터렉션이 없다는 말은 사실이 아닙니다. 스펙에서 논외로 하고 있긴 하지만 말이죠.
또한 OAuth 동작 과정에서 Consumer는 Service Provider와 사전에 신뢰 관계를 맺고 있어야 합니다. oauth_consumer_key와 서명 키를 공유하고 있어야 하기 때문이죠. 신뢰 관계를 맺어야 한다는 것은 생각보다 복잡한 문제죠. 다른 블로거들이 왜 이 점에 대해서는 언급하고 있지 않는지 모르겠습니다.
그리고 OAuth의 장점은 필요한 권한만을 제공한다는 것인데, 어떤 식으로 적절한 수준의 권한을 할당할지에 대한 내용은 논외로 하고 있습니다. 프로토콜 레벨에서 권한을 명세할 수도 있는데, 구현 과정에서의 이슈로 넘겨버렸네요.

OAuth는 여러 분야에서 활용될 전망입니다. 최근 이슈가 되고 있는 portable social network라든지, OpenID와 결합하는 방식이 논의되고 있는 상황입니다.

관심있으신 분은 OAuth 커뮤니티(구글) 를 살펴보시기 바랍니다. OAuth는 이미 PHP, Rails, Python, .NET, C, Perl 로 오픈소스 라이브러리가 개발되었으며, Bloglines가 OpenID와 OAuth를 지원 하는 것을 시작으로 Netflix, Threadless, Bloglines, Twitter, Jaiku, Pownce, Ma.gnolia 등에 적용될 예정입니다. OAuth 스펙을 작성한 사람들이  Google, Amazon, Yahoo/Flickr, Six Apart 에 일하고 있기 때문에 이들 사이트에도 적용되길 기대합니다.

참고자료
[1] http://www.whurley.com/blog/2007/10/oauth-core-10-s.html
[2] http://notizblog.org/2007/10/05/oauth-core-10-final-draft/
[3] http://kveton.com/blog/2007/10/04/oauth-goes-final-here-comes-the-open-web/
[4] http://feeds.feedburner.com/~r/PlanetIdentity/~3/165550030/oauth-10-releas.html
[5] http://feeds.feedburner.com/~r/PlanetIdentity/~3/164745962/
[6] http://daveman692.livejournal.com/315122.html
[7] http://codetechnology.wordpress.com/2007/09/27/oauth-protocol/
[8] http://feeds.feedburner.com/~r/oreilly/radar/atom/~3/161266917/oauth_open_auth.html
[9] http://feeds.feedburner.com/~r/PlanetIdentity/~3/160264746/oauth-10-public.html
[10] http://identity20.com/?p=131
[11] http://simonwillison.net/2007/Sep/21/oauth/
[12] http://feeds.feedburner.com/~r/PlanetIdentity/~3/146636497/oauth_approaches.html

title; Data Sharing Summit
link; http://vquill.com/2007/07/data-sharing-summit.html

소셜 네트워크 정보를 공유하기 위한 방안을 논의하기 위하여 Data Sharing Summit이 개최된다고 합니다. 2007년 9월 7-8일, 캘리포니아 리치몬드입니다.

주로 다룰 이슈는 다음과 같습니다.

 

- interop testing between disparate systems

- standardized schemas, protocols and APIs

- mapping to proprietary platforms

- on-going efforts, including worldwide meetings

기존에 관련 프로토콜로는 OpenID의 Attribute Sharing 스펙, Liberty Alliance의 ID-SIS, XRI(eXtensible Resource Identifier)나 XDI(Xri Data Interchange)가 있죠. 그리고 각 업체마다 저마다의 OpenAPI를 제공하고 있습니다.

지난 번에 channy 님이 국내 mashup 분야가 지지부진하다는 포스팅을 하셨는데, 통일된 스펙을 여러 기업들이 적용한다면 더욱 쉽게 mashup이 이루어 질 것으로 생각합니다.

title; Identity mix-ups and the potential harm to your reputation
link; network world's identity management newsletter, 07/16/07

Identity 정보를 매쉬업할 수 있다면 매우 유용한 정보를 만들어 낼 수 있을 것입니다. 위치정보를 이용한 광고, 식습관에 맞는 요리 주문.. 제 상상력이 많이 부족한 탓에 더 좋은 예를 들기가 어렵네요^^;

Reputation is a big part of anyone’s identity, and reputation – at least digital reputation – is, in large part, built upon what someone writes online. Had not she quickly discovered the problem, it’s quite possible that reputational damage could have been done. But worse, as she noted: “What if this wasn’t my personal blog affected. What if this was, instead, my corporate ERP system affected? Or my corporate e-mail system? What happens when a hosting company mixes up the account identifiers of two different companies’ financial accounts? What could the possible cost be, in both reputation and income, of your company’s confidential data being temporarily disclosed to another company’s users? Or of your company’s identity being temporarily associated with somebody else’s confidential data?”

하지만 Identity가 잘 못 매쉬업된다면 큰 문제가 발생합니다. 해커가 악의적으로 특정 사용자의 Identity 정보를 다른 Identity와 매쉬업시킬 수 있죠. 네트 라는 영화처럼 한 사람의 신원을 통채로 날리지는 않더라도, rss 주소만 하이재킹할 수 있다면 엄청난 사건을 일으킬 수 있겠죠? 요즘에는 신문사들도 rss를 제공하니, 잘못된 기사를 올릴 수도 있겠습니다. 방금 찾아보니 'rss hijacking'= 이슈에 대한 자료가 좀 있네요. 아쉽게도 국내에는 없구요. 조만간에 정리해 볼까 합니다.

It isn’t just identity theft, or identity fraud, that you need to worry about, but lost, strayed, or misplaced identity too. Who’s watching your reputation?

이 문제는 identity 도용이나 사기 이상의 문제라고 Dave는 말합니다. 만일 제대로 공격이 가능하다면 쉽게 막을 수 없겠죠. 최선의 방법은 암호화일까요? 이창희님이 소개한 내용 이 좋은 해결책이 될 수 있을 것 같습니다.