로고
**오픈아이디**(OpenID)는 비영리 재단인 OpenID 재단(OpenID Foundation)에서 관리하는 인증 수단이다. 오픈아이디는 분산형 디지털 정체성 시스템으로 모든 사용자들의 온라인 정체성이 URL로 주어지거나(블로그나 홈페이지처럼) 최근의 버전에서는 XRI로 주어지며 이 프로토콜을 지원하는 어떤 서버를 통해서나 인증될 수 있다. 버전 1.1부터 OpenID는 Yadis 서비스 발견 프로토콜을 사용한다.

장점
--

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

개발
--

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

용어
--

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), 예를 들면 로 변형한다. 그러면 OpenID 1.0에서 relying party는 그 URL 이 가리키는 웹페이지를 요청하고 HTML link 태그를 통해서 ID 제공 서버가  임을 알아낸다. 또한 *위임된 식별자(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`에 로그인 하지 않은 경우라면 비밀번호 입력을 요청받을 것이며, 를 신뢰하는지 묻는다. 이때 그 페이지는 인증 완료후 돌아가게 될 `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는 피싱 공격에 취약하다는 비판이 있다( Archived 2014년 9월 23일 - 웨이백 머신 ).