Mimul's Developer World - Digital Identity category

OAuth vs XAuth

Mon, 26 Apr 2010 10:26:00 GMT

아래 참조 사이트에서 참고하여 OAuth와 XAuth의 차이점을 설명하고, 개인적인 이슈 및 확장되는 흐름을 넣어 봤습니다.

1. OAuth 개요
- 제휴 절차없이 Third Party(예-twtkr.com)어플에서 쉽게 Service Provider(예-twitter.com)의 컨텐츠를 활용(공유)하여 서비스를 만들게 하기위해서 만든 규약임.
- OAuth 권한 관리쪽 개념이 강해 OpenID(인증)와는 구별됨
- 프로세스
   . OAuth는 Third Party가 필요한 access token을 공유하기 위해 3단계 프로세스가 존재하는데, 비 인가된 request token 획득, 사용자로부터 권한을 인가받는 Authorize 단계, 인가된 접근 권한을 줄 수 있는 access token을 받는 3단계로 구성됨
   . OAuth의 프로세스는 대부분 브라우저 기반으로 서비스되는 콘텐츠에서 활성화됨(프로세스의 특성상 2번째 단계에서 사용자로부터 권한 인가를 받는 Authorize 단계가 있어서 그러함)
- 아이디와 패스워드 입력 부분은 Service Provider에서 제공함(Third Party 관여 안함)

2. XAuth 개요
- 출현 배경은 OAuth의 3단계 프로세스 방식이 브라우져 기반이어서 모바일이나, 데스크탑 어플 등의 클라이언트에서 활용하는데 한계가 대두됨.
- 프로세스는 Third Party에서 아이디, 패스워드, 모드 정보를 Service Provider에 주면 바로 인가된 접근 권한을 줄 수 있는 access token을 제공하는 2단계로 구성됨.
- XAuth가 OAuth WRAP/2.0으로 통합되어 OAuth 버전이 업데이트 중임(draft)
- 아이디와 패스워드 입력 부분은 Third Party에서 제공함
- 개인적으로 생각하는 이슈
   . OAuth는 아이디와 패스워드 정보를 Service Provider에서 직접 사용자로부터 입력 받는데 반해, XAuth는 제휴가 안된 Third Party에서 직접 아이디/패스워드를 입력하여 Service Provider로 넘어옴으로 인한, 악의적인 Third Party일 경우 아이디/패스워드가 유출될 가능성 존재

3. 요약
- 브라우저 기반일 경우 OAuth 표준을 사용하면서 모바일이나 클라언트 등에는 XAuth 표준을 활용하여 서비스의 진입접을 확대하는 프로바이더를 구성해야함.
- OAuth표준이 Open Stack 진영에서 두각을 나타내면서, 기존 서비스 영역 뿐만 아니라, OAuthIMAP(Google)을 통한 메일 공유, 더 나아가 XMPP와 결합한 메신저 등의 커뮤니케이션 영역으로 확산될 것으로 예측됨.
- 또한 Identity 진영에서 본다면, IDP as a Service 형태의 비즈니스 모델로도 가능성이 있어 보임.

[참조 사이트]

구글 identity 종착역은 IDP as a Service

Mon, 15 Mar 2010 11:08:00 GMT

구글은 서비스의 공유 정책을 활성화하기 위한 identity 전략은 끝이 없어 보입니다. 역시 구글은 연구 대상입니다. 뭐든.....identity의 모든 기술들이 다 나와있다고 봐도 과언이 아닙니다.

1. Federated Login
- OpenID discovery 방식으로 인증 서버를 찾아서 Third Party에서 구글 아이디, 개인 정보를 attributes에 실어서 구글의 OpenID 로그인 프로세스를 통해 Third Party서비스에서 필요한 개인 정보를 받아오는 형식을 취하고 있음.
- IDP as a Service (OpenID & SAML)로 확장하고픈 구글의 속내가 보임.
- 참고 사이트 : Usability Research on Federated Login(http://sites.google.com/site/oauthgoog/UXFedLogin), Federated Login box (Email only - http://sites.google.com/site/oauthgoog/UXFedLogin/emailonlylogin)

2. OAuth 지원
- 구글은 Hybrid Protocol (OAuth + OpenID)도 지원하고 이메일 계정에 대한 OAuth도 지원하고 있음
- 2.0 스펙인 OAuth WRAP Profile도 지원 예정임.
- 구글의 모든 Open API를 통해 공유되는 데이터는 기본적으로 OAuth를 지원하고 있음.
- 참고 사이트 : OAuth for Web Applications(http://code.google.com/intl/ko-KR/apis/accounts/docs/OAuth.html), User Interface(http://sites.google.com/site/oauthgoog/oauth-practices/user-interface)

3. 메일 공유 정책
- OAuthIMAP(OAuth with IMAP)을 통해 적용함
IMAP AUTHENTICATE, SMTP AUTH 커맨드상에 SASL 메카니즘과 XOAUTH를 활용했습니다. 그리고 2-legged OAuth, 3-legged OAuth 모두 지원함.
- 참고 사이트 : OAuth with IMAP(http://sites.google.com/site/oauthgoog/Home/oauthimap)

4. Hybrid Protocol (OAuth + OpenID)
- OpenID OAuth Extension 표준 방식에 Association Protocol을 확장하는 방식으로 적용함.
- OpenID OAuth Extension은 OpenID에도 Proposal한 상태임.
- OAuth extension Supporting Unregistered Consumers 표준로 Proposal한 상태임.
- 참고 사이트 : OpenID OAuth Extension(http://step2.googlecode.com/svn/spec/openid_oauth_extension/drafts/0/openid_oauth_extension.html), Protocol Description(http://sites.google.com/site/oauthgoog/Home/protocol-description), Extended Association Protocol(http://sites.google.com/site/oauthgoog/Home/extended-association-protocol-for-joint-openidoauth)

identity 기술의 모든것이 녹여져 있네요. OAuth, OpenID, SAML, XRDS, SaaS, Strong/2ndFactorAuth, InformationCards/CardSpace, OpenSocial, Portable Contacts, WS-*, Geneva 등 Open Stack도 포함되어 있고 DataPortability......결국 종착역은 IDP as a Service 겠죠?

OIX등의 활동이나 Google의 행보를 보면 민/관이 시너지를 높일 수 있는 방안들이 외국에서는 많이 사례들이 나오는 상황과 달리 우리나라의 상황을 보노라면......
우리나라 개발자들이 지속적으로 이런 기술들을 적용한 서비스를 만들어서 정책 입안자들에게 규제의 타래를 조금씩 풀게 할 수 있는 방법을 찾아봐야 할 것 같습니다.

[관련 포스트]

구글과 페이팔의 Open Identity Exchange(OIX) 기반의 새로운 인증 시스템

Mon, 08 Mar 2010 11:41:00 GMT

아래 내용은 Google and PayPal to Support New Government Login System의 아티클을 보고 간략하게 리뷰해 보았습니다. 관련 종사자분들은 참고하세요. 그리고 제가 잘못 이해한 부분이 있다면 댓글로 지적바랍니다.

*. 개요

- 미국의 제휴 표준(identity federation)의 한 형태로 기업간의 Pubic identity이든, Private identity 영역이든 제휴 기업간의 온라인 기반의 서비스에서 SSO를 위해서 정부의 공식적은 제안으로 Google, PayPal, Equifax, VeriSign, Verizon, CA and Booz Allen Hamilton이 모여 RSA 컨퍼런스에서 공식화함
- 기존 기업간의 내부 ID에 대한 private 개념의 SSO 표준인 SAML(Liberty-alliance- VeriSign, Sun이 주도함)방식이 추진되었었는데, 이번 컨퍼런스에서는 OIX기반의 Public 인터넷 기반으로 고객(구글, 페이팔 등의 고객도 수용하는)으로 확장되었다고 볼수 있음
- 이 위원회가 출범하는 것의 의미는 기술 주도의 흐름에서 마켓 주도로 Identity management system이 변화되고 있다고 생각되며, 많이 확보된 고객 기반을 가지고 있는 플랫폼들의 개방 및 연계가 증가할 것으로 보여 더더욱 확고한 Identity management system이 될 것으로 보임.

*. OIX 프로세스

- Identity Service Provider(Google, PayPal, Equifax, VeriSign, Verizon, CA and Booz Allen Hamilton)와 Relying Party(U.S. Government sites )간의 정책(보안 및 프라이버시)기반의 공통 신뢰 프레임워크를 구축하여 Open Government를 위한 Open Identity Provider 제공
- 기존 표준기반의 OpenID and Information Card는 Relying Party간의 SSO는 이루어지지만, 보안 및 프라이버시 정책의 공유가 없어서 서로 신뢰의 수준이 다른 문제점 및 한계를 극복하기 위해 정부 등 다양한 기업의 신뢰 네트워크가 구축된 사이트간의 보안 및 프라이버시 정책 프레임워크를 공유한 사이트간의 표준 기반의 SSO를 확장할 수 있는 것이 특징임

Identity Management 시스템의 기술 진영의 세가지 패러다임인

URL 기반의 OpenID 플랫폼
WS*-based 방식의 Microsoft,
Liberty Based Sun, Novel, Verisign등의 진영에서

마켓 주도의 시장 형성으로 바뀌어가는 느낌이 많이 듭니다. OIX가 결성된 것을 보면.....
그리고 어떤 표준 형태로 구축될지 관심이 가는 대목입니다.

[참고 사이트]

Google and PayPal to Support New Government Login System

OAuth1.0a + OAuth Access Tokens using credentials draft

Wed, 17 Feb 2010 11:09:00 GMT

Twitter.com에서 2-legged 방식으로 access token을 제공하는 방식의 OAuth Access Tokens using credentials draft 스펙을 적용해서 운영을 하고 있군요. 이에 대해 분석을 좀 해 봤습니다.

1. 배경
- 기존에는 웹 방식으로 3-legged 방식으로 진행되어 웹이 지원되지 않는 클라이언트 어플에서 한계점이 있었음.
- OAuth WRAP/2.0이 아직 안나와서 OAuth Access Tokens using credentials draft + OAuth 1.0a를 트위터에서 구현한 것임.
- 이 스펙의 draft로 인해 클라이언트 및 모바일 어플에서도 확장되어 사용할 가능성이 많아 보임.

2. 개요
- OAuth1.0a + OAuth Access Tokens using credentials draft(xAuth) 개념 도입함.
- xAuth : x_auth_mode, x_auth_username, x_auth_password 요청 파라미터에 추가되었음.
- 기존은 3-legged 방식이었는데 이 방식은 2-legged 방식으로 변환되어 바로 access token을 제공하여 이 토큰을 가지고 보호 개인 콘텐츠들을 공유할 수 있는 기반을 마련해 줌.
- Third Party(Consumer)에서는 아이디/패스워드는 관리하지 않고 access token만 관리를 하게 됨.
- OAuth WRAP/2.0는 FriendFeed, Facebook에서 적용하고 있음.

3. OAuth Access Tokens using credentials draft 상세 정보
*. 요청시 파라미터
- x_auth_mode=client_auth
- x_auth_username=트위터 아이디
- x_auth_password=트위터 패스워드
- oauth_consumer_key : 트위터에서 발급한 consumer 인증용 키
- oauth_signature_method : 시그너처 암호화 방법
- oauth_signature : 시그너처
- oauth_timestamp : 요청 시간
- oauth_nonce : phishing용 방어 Nonce
- oauth_version : OAUTH 스펙 버전(1.0)

*. 요청 응답 파라미터(아래 파라미터만 Consumer 사이트에서 관리함)
- oauth_token : TwitterPic에서 이미지 공유가능하도록 접근 허용 키 발급(access token)
- oauth_token_secret : 키에 대한 credentials 값
- x_auth_expires : 인증 세션 만료 기간(0:무기한, 만료되었을 경우 Consumer 사이트는 재 인증 절차를 밟아야 함)

4. 이슈
- username, password 정보를 Third-Party에서 저장해서 관리할 가능성 존재.
- Phishing Attacks, Session Fixation Attacks의 OAuth 자체가 안고 있는 보안 이슈에 대해서도 보완도 필요해 보임.

[참조사이트]

OAuth 스펙을 활용한 Twitter API 놀이

Wed, 02 Dec 2009 11:17:00 GMT

1. 관련 라이브러리 카피
- twitter4j-2.0.10.zip 다운로드
- twitter4j-2.0.10.jar 파일을 WEB-INF/lib에 카피

2. twitter consumer key와 secret정보 등록
- 등록 사이트 : http://twitter.com/apps/new
- twitter api 사이트 : http://apiwiki.twitter.com/Twitter-API-Documentation
- OAuth 처리 URL 정보(https://twitter.com/oauth/request_token, https://twitter.com/oauth/authorize, https://twitter.com/oauth/access_toke)

3. 관련 샘플 소스
- 위 라이브러리를 활용한다면 twitter.getOAuthRequestToken();, twitter.getOAuthAccessToken(requestToken, pin);를 통해 access token, access secret를 가져오거나
- 자체 웹 방식으로 구현해서 access token, access secret을 가져온다.
- 특이하게 twitter에서는 access token을 가져올 때 user_id값과 screen_name 정보를 가져올 수 있다. 이 정보를 활용하여 Timeline, Status, Account, Mentions 등의 정보를 가져올 수 있다.
- 컨슈머키와 시크릿, access key와 access token을 할당하여 Statuses 정보를 가져오는 샘플

 
AccessToken accessToken = null; 
try {
        twitter = new Twitter();
        twitter.setOAuthConsumer(accessor.consumer.consumerKey, 
           accessor.consumer.consumerSecret);
        accessToken = new AccessToken(accessor.accessToken,
          accessor.tokenSecret);
        twitter.setOAuthAccessToken(accessToken);
        statuses = twitter.getFriendsTimeline();
} catch (Exception e) {
	e.printStackTrace();
	request.setAttribute("statuses", null);
}

4. 데모 사이트
- http://mimul.com/oauth-consumer/

[관련 포스트]