OpenID
위키백과 ― 우리 모두의 백과사전.
 |
이 문서는 편집 지침에 맞춰 다듬어야 합니다. 이 문서를 정리해 주세요. |
오픈아이디(OpenID)는 웹에서 자신의 계정을 통합적으로 관리하는 방식으로, 흔히 쓰이는 중앙집중식 로그인에 비해 비교적 느슨한 방식으로 사용자를 인증한다.
즉 각각의 사이트에서 아이디와 비밀번호를 관리하는 대신, 오픈아이디를 지원하는 사이트에서는 사용자 인증을 독립된 각 서비스 제공자에게 맡기고, 그러면 개별 오픈아이디 제공자가 사용자를 인증해 준다.
2007년 현재, 많은 사이트에서 채택하고 있으며, 위키백과나 테크노라티 같은 곳도 지원을 발표하였으며 모질라 파이어폭스[1]와 마이크로소프트의 윈도 비스타[2]에서도 오픈아이디를 지원하기로 했다.
목차 |
[편집] 개요
오픈아이디는 분산형 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 시스템은 원래 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 씩을 제안하고 있다. [3]
[편집] 용어
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 에 접속할 때 사용하는 (브라우저 등) 프로그램.
[편집] 오픈아이디 작동 방식
사용자가 오픈아이디 로그인을 제공하는 웹 사이트에 로그인을 하려면, 일반적인 사이트에서는 아이디와 비밀번호를 입력해야 하는 것과 달리, 오픈아이디를 이용한 로그인에서는 자신의 오픈아이디만 입력하면 된다. 예를 들어, 만약 Alice라는 사용자가 example.com라는 사이트에 alice.openid-provider.org라는 오픈아이디로 로그인한다고 하면, Alice는 그 사이트의 오픈아이디 로그인 폼에 alice.openid-provider.org를 입력하면 된다.
만약 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+xml 인 XRDS 문서 (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.com 에 alice.openid-provider.org 으로 로그인한 것으로 간주된다. 그러면 그 사이트는 세션을 저장하거나, 만약 처음 로그인 하는 경우라면, 가입을 완료하기 위해서 example.com 고유의 추가 정보를 입력하도록 요구될 수도 있다.
[편집] 비판
OpenID는 피싱 공격에 취약하다는 비판이 있다([1]).
[편집] 참조
- ↑ Firefox 3 Requirements
- ↑ The Register: “Gates: protect Windows Vista users with IP”
- ↑ I Want My OpenID 공공 장려금 프로그램을 포함한 커뮤니티 마케팅 사이트(장려금 스폰서)
[편집] 바깥 링크
- openid.net (영어)
- OpenID Asia Organization - Foundation for promoting OpenID in Asia
- OpenID 한국어 / OpenID 한국 커뮤니티
- identity.eastmedia.com — OpenID and Identity info at eastmedia
- OpenID Enabled — OpenID 개발자 리소스
- OpenID 지원 사이트들 / 한국 OpenID 지원 사이트
- OpenID 제공서버들 (Servers)
- MediaWiki Patch - 공식 MediaWiki OpenID 패치
- OpenID Europe Foundation
