OpenID

위키백과 ― 우리 모두의 백과사전.

OpenID 는 분산형 digital identity 시스템으로 모든 사용자들의 online identity 가 URL로 주워지거나(blog 나 홈페이지 처럼) 최근의 버전에서는 XRI로 주워지며 이 프로토콜을 지원하는 어떤 서버를 통해서나 인증될 수 있다. 버전 1.1 부터 OpenID 는 Yadis 서비스 발견 프로토콜을 사용한다. OpenID 가 인증(authentication)이외의 다른 identity 서비스들도 지원하는 좀더 완결된 프레임워크(framework)로 개발되고 있지만, 현재 OpenID Authentication 2.0 개발 작업이 진행중이다.

OpenID 지원 사이트에서 Internet 사용자들은 모든 사이트에 입장할 때마다 새로운 계정을 만들고 관리할 필요가 없게 된다. 대신, 그들은 identity 제공자 (또는 줄여서 idP, 간혹 i-broker)라고 하는 OpenID 제공하며 그들이 신뢰하는 하나의 사이트에서만 인증하면 된다. 그 identity 제공자는 그 사용자의 해당 ID 에 대한 소유권을 OpenID 지원사이트 (relying parties 또는 RPs) 에 입증해 줄 수 있다. 대부분의 다른 single sign-on 구조와 달리, OpenID 는 특정 인증(authentication) 메카니즘을 명시하지 않는다. 따라서 OpenID 인증의 강도는 전적으로 OpenID 지원사이트가 OpenID 제공자의 인증 정책에 대해 얼마나 많이 알고 있는가에 달려있다. 만약 그러한 정보가 없다면 OpenID 는 매우 민감한 정보(금융 banking, 전자상거래 e-commerce 같은 ) 를 다루는데 사용되지는 못할 것이다. 그러나 만약 identity 제공자가 strong authentication를 사용한다면, OpenID 는 모든 종류의 거래에 사용될 수 있다.

OpenID 는 현재 많은 사이트들에 의해 채택이 증가하고 있으며, 위키피이아나 Technorati 같은 곳도 지원을 발표하고 있다.

목차

[편집] 개발

OpenID 시스템은 원래 LiveJournal 의 Brad Fitzpatrick 에 의해 개발되었지만, VeriSign 의 David Recordon, JanRain 의 Josh Hoyt, 그리고 Sxip 의 Dick Hardt 도 현재 공동 개발자이다. 향후의 OpenID 스펙은 specs@openid.net 을 통해 능력 위주 방식(meritocratic) 으로 개발되고 있다. 더 추가적인 개발을 낳기 위해서 몇몇 업체들이 미화 $50,000 개발자 장려금 프로그램을 2006 년 8월에 발표했으며, OpenID 지원을 구현하는 대규모 오픈 소스 프로젝트 처음 10 개에 각각 $5,000 씩을 제안하고 있다. [1]

[편집] 용어정리

OpenID 에 사용되는 기본 용어들:

  • 최종 사용자 (end user) — 자신의 identity 를 어떤 사이트에 밝히고자 하는 사람.
  • ID (identifier) — 최종 사용자가 그들의 OpenID 아이디로 선택한 URL 이나 XRI.
  • ID 제공자 (identity provider) — OpenID URL 또는 XRI 등록을 제공하고 OpenID 인증 (추가적으로 다른 identity 서비스도) 을 제공하는 서비스 제공자.
  • relying party — 최종 사용자의 ID를 검증하고자 하는 사이트.
  • server 또는 server-agent — 최종 사용자의 ID를 검증해주는 서버로, 최종 사용자의 자체 서버 (블로그 등) 또는 ID 제공자에 의해 운영되는 서버가 될 수 있다.
  • user-agent — 최종 사용자가 ID 제공자나 relying party 에 접속할 때 사용하는 (브라우저 등) 프로그램.

[편집] OpenID 는 어떻게 작동하나

어떤 웹사이트, 이를 테면 example.com, 가 방문객들에게 OpenID 로 로그인 할 수 있게 하기 위해 사이트 어느 페이지엔가 로그인 폼을 제공한다. 전형적인 로그인 폼들이 사용자에게 이름과 비밀번호를 요청하는 것과 달리 오직 OpenID ID 만 입력하게 되어 있다. 그 사이트는 그 입력란 옆에 작은 OpenID 로고 이미지를 보여줄 수도 있다. 이 폼은 OpenID 클라이언트 라이브러리와 연결되어 있다.

만약 Alice 라는 이름의 사용자가 example.com 에, ID 제공자 openid-provider.org 에 등록한 alice.openid-provider.org 라는 OpenID ID 로 로그인 하길 원한다면, 그녀는 example.com 에 가서 OpenID 로그인 란에 alice.openid-provider.org 를 입력하기만 하면 된다. OpenID 인증 2.0 (몇몇 OpenID 1.1 구현을 포함해서) 부터는, Alice 는 =example.alice=example.community*alice 와 같은 i-name 을 입력해서 로그인 할 수도 있다.

만약 ID 가 URL 이라면, relying party (example.com) 는 먼저 URL 을 대표형태(canonical form), 예를 들면 http://alice.openid-provider.org/, 로 변형한다. 그러면 OpenID 1.0 에서 relying party 는 그 URL 이 가리키는 웹페이지를 요청하고 HTML link 태그를 통해서 ID 제공 서버가 http://openid-provider.org/openid-auth.php 임을 알아낸다. 또한 위임된 식별자(delegated identity) (아래를 보시오) 를 사용하는 지도 알아 낸다. OpenID 1.1 부터 클라이언트는 컨텐츠 유형이 application/xrds+xmlXRDS 문서 (Yadis 문서라고도 함) 를 요청해서 알아낼 수도 있으며, 이때 그 문서는 그 URL 로 접근될 수 있거나 XRI 로 항상 접근 될 수 있다.

relying party 가 ID 제공자와 통신하는 두가지 모드가 있다:

  • checkid_immediate, 이것은 컴퓨터 중심의 방식으로 두 서버간의 모든 통신이 사용자 간섭없이 이루어 진다;
  • checkid_setup, 여기선 사용자가 직접 웹브라우저를 통해서 ID 제공자 서버와 통신을 하여 relying party 사이트에 접속한다.

두번째 방식이 웹에서는 좀더 많이 사용된다; 또한 자동 처리가 불가능할 경우 checkid_immediate 대신 checkid_setup 방식이 사용된다.

첫번째 단계는 (선택적이지만) relying party 와 제공자간에 공유되는 보안정보(associate handle)를 만들고, relying party 가 그 보안정보를 저장해 두는 것이다. checkid_setup 를 사용하는 경우 relying party 는 사용자의 웹브라우저를 제공자에게 보낸다. 이 경우 Alice 의 브라우저는 openid-provider.org 로 보내지고 Alice 는 제공자와 직접 인증을 할 수 있게 된다.

인증 방식은 달라 질 수 있지만, 전형적으로는, OpenID 제공자가 비밀번호 입력을 요청한다 (그러면, 비밀번호 기반 인증을 사용하는 많은 웹사이트들 처럼, 쿠키로 사용자 세션을 저장하거나 할 수 있다). Alice 는 아직 openid-provider.org 에 로그인 하지 않은 경우라면 비밀번호 입력을 요청받을 것이며, http://example.com/openid-return.php 를 신뢰하는지 묻는다. 이때 그 페이지는 인증 완료후 돌아가게 될 example.com 의 한 페이지로 그녀의 identity 세부사항이 전달된다. 만약 그녀가 허용할 경우 OpenID 인증이 성공된 것으로 간주되며 브라우저는 인증서(credentials)를 가지고 그 페이지로 돌려보내 진다. 만약 Alice 가 그 relying party 를 신뢰하지 않는다고 해도 브라우저는 그 페이지로 돌려보내 지지만, 요청이 거부된 것이 통보되기 때문에 이번엔 example.com 이 Alice 를 인증하지 않을 것이다.

그러나, 아직 로그인 절차가 끝나지 않았다, 왜냐하면 이 단계에서 example.com 은 받은 인증서(credential)가 정말 openid-provider.org 에서 온 것인지 결정할 수 없기 때문이다. 만약 이전에 공유된 보안정보를 만들어 두었다면 consumer 가 받은 인증서(credential)을 그 보안정보로 검증할 수 있다. 이러한 cunsumer 는 세션간의 공유된 보안정보를 저장해 두기 때문에 stateful 하다고 말한다. 반면 stateless 또는 dumb consumer 는 하나의 서버간 요청 (check_authentication)을 더해야만 그 데이타가 정말 openid-provider.org 에서 온 것인지 보장할 수 있다.

일단 Alice 의 ID 가 검증된 후에는 그녀는 example.comalice.openid-provider.org 으로 로그인한 것으로 간주된다. 그러면 그 사이트는 세션을 저장하거나, 만약 처음 로그인 하는 경우라면, 가입을 완료하기 위해서 example.com 고유의 추가 정보를 입력하도록 요구될 수도 있다.

[편집] References

  1. I Want My OpenID 공공 장려금 프로그램을 포함한 커뮤니티 마케팅 사이트(장려금 스폰서)

[편집] External links