OAuth는 과연 성공할 것인가?

OAuth의 기본 개념은 맘에 듭니다. 사이트에 정보를 제공할 때에 내가 원하는 부분만 제한하여 제공해주자는 것이죠. 기존 서비스의 경우에는 api-key나 id/pass를 넘겨주어, 사용자가 할 수 있는 모든 일을 처리할 수 있었습니다. 언제든지 무슨 일이든 할 수 있기 때문에 보안상으로는 매우 취약하죠. 실례로, "Mint"라는 해외의 재무사이트는 모든 은행의 id/pass를 입력받아 계좌 내역을 통합관리할 수 있지만, 해킹이나 악의적인 목적으로 id/pass가 노출된다면 심각한 문제가 될 것입니다. 국내외에 이런 서비스가 상당히 많습니다.

He adds that it's now becoming common for financial-management sites such as Mint to ask for passwords in order to aggregate information for users. In addition to posing a security risk, Hammer-Lahav says, it's actually not the best way for sites to share information. The aggregator sites often have to scrape financial information off banking pages by training their software to seek certain clues in the page source that signal key pieces of data. The problem, he says, is that if the bank redesigns the look of a page, those clues might change, rendering the aggregator unable to read the information. A system such as OAuth, Hammer-Lahav says, allows the sites to share information directly.


open social network와 관련하여 나오는 친구 찾기 서비스 같은 것들 또한 email 주소와 패스워드를 넣는 방식을 사용하더군요. 어쩔 수 없죠. 정보를 가지고 있는 사이트에는 정작 해당 정보를 공유할 수 있는 기능이 없으니깐요.


출처: http://flickr.com/search/?q=antipattern&w=25419820%40N00

Facebook Needs OAuth
출처: http://factoryjoe.com/blog/2007/12/19/public-nuisance-1-importing-your-contacts/

OAuth가 효과를 발휘하려면 사용자의 정보를 관리하고 있는 측에서 적극적으로 수용해야 합니다. 하지만 현실적으로는 어렵죠. 자신들의 강점이 녹아있는 정보를 공유해야 하기 때문입니다. 물론 정보를 관리하는 측과 사용하는 측이 윈-윈할 수 있는 방법이 있다고 생각할 수 있겠죠. 하지만 제 성격이 이상해서 그런지, 사용하는 측에서 한 번 중요 정보를 끌어와서 더 나은 서비스를 계속 제공하지 않을까라는 생각이 드는군요. 사용하는 측의 이점이 더 많기 때문에 id/pass 방안, 기껏해야 api-key 방안이 도입되었다고 결론을 내렸습니다. api-key를 이용한 방안도 살펴보면 api-key를 제공함으로써 정보를 관리하는 측이 이점을 가지는 경우이고, 해당 서비스 또한 정보를 관리하는 측에서 만든 경우가 많습니다.

이렇게 써놓고 OAuth에 대해 쓴 이전 포스팅 을 찾아보니, 그 때와 똑같은 논조네요.

이 글과 관련있는 글을 자동검색한 결과입니다 [?]

by S_H_Kim | 2008/01/01 16:55 | CardSpace | 트랙백

◀ 이전 페이지다음 페이지 ▶