오픈아이디

오픈아이디 로고

오픈아이디(OpenID)는 비영리 단체인 오픈아이디 재단이 추진하는 개방형 표준이자 분산형 인증 통신 프로토콜이다. 이는 사용자가 제3자의 아이디 제공자(IdP) 서비스를 사용하여 협력 사이트(이를 의존 당사자(RP)라고 함)에서 인증을 받을 수 있게 해준다. 이를 통해 웹마스터가 자체적인 임시 로그인 시스템을 구축할 필요가 없으며, 사용자는 각 웹사이트마다 별도의 아이디와 비밀번호를 만들지 않고도 서로 관련 없는 여러 웹사이트에 로그인할 수 있다. 사용자는 오픈아이디 아이디 제공자를 선택하여 계정을 생성하고, 그 계정을 사용하여 오픈아이디 인증을 지원하는 모든 웹사이트에 로그인한다. 여러 대형 조직이 자사 웹사이트에서 오픈아이디를 발행하거나 수락하고 있다.

오픈아이디 표준은 아이디 제공자와 오픈아이디 수락자("의존 당사자") 사이에서 이루어져야 하는 통신을 위한 프레임워크를 제공한다. 이 표준의 확장 기능인 '오픈아이디 속성 교환'(OpenID Attribute Exchange)은 이름이나 성별과 같은 사용자 속성을 아이디 제공자로부터 의존 당사자로 전달하는 것을 용이하게 한다(각 의존 당사자는 요구 사항에 따라 서로 다른 속성 세트를 요청할 수 있다). 오픈아이디 프로토콜은 사용자의 신원을 인증하기 위해 중앙 권한에 의존하지 않는다. 게다가 서비스나 오픈아이디 표준 모두 사용자를 인증하는 특정 방식을 강제하지 않으므로, 일반적인 방식(비밀번호 등)부터 새로운 방식(스마트카드, 생체 인식 등)에 이르기까지 다양한 접근 방식을 허용한다.

오픈아이디의 최종 버전은 2007년 12월에 확정 및 발표된 오픈아이디 2.0이다. '오픈아이디'라는 용어는 오픈아이디 표준에 명시된 식별자를 지칭하기도 한다. 이러한 식별자는 고유한 통합 자원 식별자(URI) 형태를 띠며, 인증을 처리하는 "오픈아이디 제공자"에 의해 관리된다.

도입

2016년 3월 기준 기준으로 인터넷상에는 10억 개 이상의 오픈아이디 활성화 계정이 존재하며, 약 1,100,934개의 사이트가 오픈아이디 소비자 지원을 통합했다: AOL, 플리커, 구글, 아마존닷컴, 캐노니컬(제공자 명칭 우분투 원), 라이브저널, 마이크로소프트(제공자 명칭 마이크로소프트 계정), Mixi, 마이스페이스, 노벨, 오픈스트리트맵, 오렌지, 시어스, 썬, Telecom Italia, 유니버설 뮤직 그룹, 베리사인, 워드프레스, 야후!, BBC, IBM, 페이팔,, 그리고 스팀 등이 포함되지만, 이들 조직 중 일부는 자체적인 인증 관리 시스템도 갖추고 있다.

페이스북은 과거에 오픈아이디를 사용했으나 페이스북 커넥트로 이전하였다. 블로거(Blogger) 역시 오픈아이디를 사용했으나 2018년 5월부터는 더 이상 지원하지 않는다.

기술 개요

오픈아이디는 사용자가 단일 자격 증명 세트를 사용하여 여러 웹사이트에서 인증을 받을 수 있도록 하는 분산형 인증 프로토콜로, 각 웹사이트마다 별도의 아이디와 비밀번호를 사용할 필요를 없애준다. 오픈아이디는 아이디 제공자(IdP)를 통해 사용자를 인증하며, 아이디 제공자는 사용자에게 고유한 식별자(오픈아이디라 함)를 제공한다. 이 식별자는 오픈아이디를 지원하는 모든 웹사이트에서 사용자를 인증하는 데 사용될 수 있다.

사용자가 오픈아이디 인증을 지원하는 웹사이트를 방문하면, 해당 웹사이트는 사용자를 선택한 IdP로 리다이렉트한다. 그러면 IdP는 사용자에게 인증(예: 아이디 및 비밀번호 입력)을 요구한다. 사용자가 인증되면 IdP는 오픈아이디를 생성하여 해당 웹사이트로 다시 보낸다. 웹사이트는 실제 자격 증명을 알 필요 없이 이 오픈아이디를 사용하여 사용자를 인증할 수 있다.

오픈아이디는 HTTP, HTML, XML을 포함한 기존의 여러 표준 위에 구축된다. 오픈아이디는 특정 오픈아이디와 관련된 IdP를 웹사이트가 찾을 수 있도록 하는 검색 메커니즘과 피싱 및 기타 공격으로부터 보호하기 위한 보안 메커니즘 등 여러 기술에 의존한다.

오픈아이디의 주요 장점 중 하나는 사용자가 개별 웹사이트에 로그인 자격 증명을 저장하고 관리하도록 하는 대신, 자신의 신원 정보를 직접 제어할 수 있게 한다는 점이다. 이는 웹사이트가 보안 침해에 취약하거나 사용자가 개인 정보 보호를 우려하는 경우에 특히 중요할 수 있다.

오픈아이디는 구글, 야후!, 페이팔을 포함한 다수의 대형 웹사이트 및 서비스 제공업체에 의해 널리 채택되었다. 또한 루비 온 레일즈와 장고 등 여러 오픈 소스 프로젝트 및 프레임워크에서도 이 프로토콜을 사용한다.

로그인

최종 사용자는 인증을 위해 오픈아이디를 지정할 수 있는 옵션을 제공하는 의존 당사자(웹사이트 등)와 상호 작용한다. 최종 사용자는 일반적으로 사전에 오픈아이디 제공자(예: openid.example.org)에 오픈아이디(예: alice.openid.example.org)를 등록해 둔다.

의존 당사자는 일반적으로 오픈아이디를 표준 URL 형식(예: http://alice.openid.example.org/)으로 변환한다.

  • 오픈아이디 1.0의 경우, 의존 당사자는 해당 URL로 식별되는 HTML 리소스를 요청하고 HTML 링크 태그를 읽어 오픈아이디 제공자의 URL(예: http://openid.example.org/openid-auth.php)을 발견한다. 또한 의존 당사자는 위임된 신원(아래 참조)을 사용할지 여부를 확인한다.
  • 오픈아이디 2.0의 경우, 의존 당사자는 application/xrds+xml 콘텐츠 유형을 가진 XRDS 문서(야디스 문서라고도 함)를 요청하여 오픈아이디 제공자 URL을 발견한다. 이 문서는 대상 URL에서 제공될 수 있으며 대상 XRI에 대해서는 항상 사용할 수 있다.

의존 당사자가 오픈아이디 제공자와 통신하는 방식에는 두 가지 모드가 있다:

  • checkid_immediate: 의존 당사자가 오픈아이디 제공자에게 최종 사용자와 상호 작용하지 않도록 요청하는 방식이다. 모든 통신은 최종 사용자에게 명시적으로 알리지 않고 최종 사용자의 사용자 에이전트를 통해 전달된다.
  • checkid_setup: 최종 사용자가 의존 당사자에 액세스하는 데 사용하는 것과 동일한 사용자 에이전트를 통해 오픈아이디 제공자와 통신하는 방식이다.

checkid_immediate 모드는 작업을 자동화할 수 없는 경우 checkid_setup 모드로 전환될 수 있다.

먼저, 의존 당사자와 오픈아이디 제공자는 (선택적으로) 연관 핸들로 참조되는 공유 비밀을 설정하고, 의존 당사자는 이를 저장한다. checkid_setup 모드를 사용하는 경우, 의존 당사자는 최종 사용자가 오픈아이디 제공자와 직접 인증할 수 있도록 최종 사용자의 사용자 에이전트를 오픈아이디 제공자로 리다이렉트한다.

인증 방법은 다양할 수 있지만, 일반적으로 오픈아이디 제공자는 최종 사용자에게 비밀번호나 암호화 토큰을 요구한 다음, 최종 사용자가 의존 당사자에게 필요한 신원 세부 정보를 제공하는 것을 신뢰하는지 묻는다.

최종 사용자가 의존 당사자를 신뢰하라는 오픈아이디 제공자의 요청을 거부하면, 사용자 에이전트는 인증이 거부되었다는 메시지와 함께 의존 당사자로 다시 리다이렉트되며, 의존 당사자는 결과적으로 최종 사용자의 인증을 거부한다.

최종 사용자가 의존 당사자를 신뢰하라는 오픈아이디 제공자의 요청을 수락하면, 사용자 에이전트는 최종 사용자의 자격 증명과 함께 의존 당사자로 다시 리다이렉트된다. 해당 의존 당사자는 자격 증명이 실제로 오픈아이디 제공자로부터 온 것임을 확인해야 한다. 의존 당사자와 오픈아이디 제공자가 이전에 공유 비밀을 설정했다면, 의존 당사자는 세션 간에 공유 비밀을 저장하는 '상태 유지(stateful)' 의존 당사자로서, 공유 비밀의 복사본을 자격 증명과 함께 받은 것과 비교하여 오픈아이디 제공자의 신원을 검증할 수 있다. 반면, 상태 비저장(stateless) 또는 '덤(dumb)' 의존 당사자는 데이터가 실제로 오픈아이디 제공자로부터 온 것임을 보장하기 위해 한 번 더 백그라운드 요청(check_authentication)을 수행해야 한다.

오픈아이디가 검증된 후 인증은 성공으로 간주되며, 최종 사용자는 주어진 오픈아이디(예: alice.openid.example.org)가 지정한 신원으로 의존 당사자에 로그인된 것으로 간주된다. 의존 당사자는 일반적으로 최종 사용자의 오픈아이디를 다른 세션 정보와 함께 저장한다.

식별자

오픈아이디를 지원하는 웹사이트에 로그인하는 데 사용할 수 있는 오픈아이디 활성화 URL을 얻으려면 사용자는 아이디 제공자에게 오픈아이디 식별자를 등록해야 한다. 아이디 제공자는 오픈아이디 인증 서비스로 자동 구성되는 URL(일반적으로 3단계 도메인, 예: username.example.com) 등록 기능을 제공한다.

오픈아이디를 등록한 후, 사용자는 자신이 제어하는 기존 URL(블로그나 홈페이지 등)을 별칭 또는 "위임된 신원"으로 사용할 수 있다. 사용자는 단순히 적절한 오픈아이디 태그를 HTML에 삽입하거나 야디스 문서를 제공하면 된다.

오픈아이디 인증 2.0(및 일부 1.1 구현)부터는 오픈아이디와 함께 사용할 수 있는 식별자로 URL과 XRI, 두 가지 유형이 있다.

XRI는 교차 도메인 디지털 신원을 위해 특별히 설계된 새로운 형태의 인터넷 식별자이다. 예를 들어, XRI는 i-name과 i-number의 두 가지 형태로 제공되며, 일반적으로 동의어로 동시에 등록된다. I-name은 (도메인 이름처럼) 재할당이 가능하지만, i-number는 절대 재할당되지 않는다. XRI i-name이 오픈아이디 식별자로 사용되면, 즉시 동의어인 i-number(XRDS 문서의 CanonicalID 요소)로 해석된다. 이 i-number가 의존 당사자가 저장하는 오픈아이디 식별자이다. 이러한 방식으로, 사용자나 의존 당사자 모두 DNS 기반의 재할당 가능한 이름에서 발생할 수 있는 오픈아이디 신원 도용으로부터 보호받을 수 있다.

오픈아이디 재단

오픈아이디 재단(OIDF)은 오픈아이디 커뮤니티와 기술을 장려하고 향상시킨다. OIDF는 오픈아이디를 홍보하고 보호하려는 개인 개발자, 정부 기관 및 기업으로 구성된 비영리 국제 표준 개발 조직이다. 오픈아이디 재단은 2007년 6월에 설립되었으며 개발자, 공급업체 및 사용자의 개방형 커뮤니티를 대표하는 공익 단체로 활동한다. OIDF는 필요한 인프라를 제공하고 오픈아이디의 채택을 장려하며 지원함으로써 커뮤니티를 돕는다. 여기에는 지적 재산 및 상표 관리뿐만 아니라 오픈아이디의 바이럴 성장과 전 세계적 참여 촉진이 포함된다.

관계자

오픈아이디 재단의 이사회는 6명의 커뮤니티 이사와 8명의 기업 이사로 구성된다:

지부

OIDF는 디지털 신원을 홍보하고 오픈아이디의 추가 채택을 장려하기 위한 글로벌 조직이며, 회원 지부 설립을 장려해 왔다. 회원 지부는 재단의 공식적인 일부이며, 인터넷상에서 사용자 중심 신원을 위한 프레임워크로서 오픈아이디의 개발과 채택을 지원하기 위해 각자의 구성원 내에서 활동한다.

지적 재산 및 기여 계약

OIDF는 오픈아이디 사양이 자유롭게 구현될 수 있도록 보장하며, 따라서 모든 기여자가 기여 계약에 서명할 것을 요구한다. 이 계약은 공동 사양을 게시할 수 있는 저작권 라이선스를 재단에 부여하며 특허 무주장 합의(patent non-assertion agreement)를 포함한다. 무주장 합의는 기여자가 오픈아이디 사양을 구현하는 사람을 고소하지 않겠다는 내용을 담고 있다.

법적 문제

미국 내 오픈아이디 상표는 2008년 3월 오픈아이디 재단에 양도되었다. 이 상표는 오픈아이디 재단이 운영되기 전에 NetMesh Inc.에 의해 등록되었었다. 유럽에서는 2007년 8월 31일 기준으로 오픈아이디 상표가 오픈아이디 유럽 재단에 등록되어 있다.

오픈아이디 로고는 2005년에 권리를 오픈아이디 조직에 양도할 계획을 밝힌 랜디 "ydnar" 레디그(Randy "ydnar" Reddig)가 디자인했다.

오픈아이디가 처음 발표된 이래, 공식 사이트에서는 다음과 같이 명시하고 있다:

아무도 이것을 소유해서는 안 된다. 누구도 이것으로 돈을 벌 계획은 없다. 목표는 이를 가능한 가장 자유로운 라이선스 하에 공개하여, 참여하는 데 돈이나 라이선스, 등록이 필요 없도록 하는 것이다. 이런 것이 존재하면 커뮤니티 전체에 이익이 되며, 우리 모두가 그 커뮤니티의 일원이다.

썬 마이크로시스템즈, 베리사인 및 오픈아이디에 참여하는 다수의 소규모 기업들은 오픈아이디 1.1 사양을 포괄하는 특허 무주장 합의를 발표했다. 이 합의는 해당 기업들이 오픈아이디 구현에 대해 특허를 주장하지 않겠으며, 오픈아이디 구현자를 상대로 특허를 위협하거나 주장하는 사람들에게는 그 약속을 철회하겠다는 내용을 담고 있다.

보안

인증 버그

2012년 3월, 연구 논문에서 오픈아이디의 두 가지 일반적인 보안 문제가 보고되었다. 두 문제 모두 공격자가 피해자의 의존 당사자 계정에 로그인할 수 있게 한다. 첫 번째 문제에 대해 오픈아이디와 구글(오픈아이디의 아이디 제공자) 모두 이를 해결하기 위한 보안 권고를 발표했다. 구글의 권고는 다음과 같다: "공격자가 사용자의 이메일 주소를 요구하지 않는 오픈아이디 요청을 위조한 다음, IdP 응답에 서명되지 않은 이메일 주소를 삽입할 수 있다. 공격자가 이 응답을 이 속성이 서명되지 않았음을 알아차리지 못하는 웹사이트로 전달하면, 해당 웹사이트가 공격자를 로컬 계정으로 로그인시키도록 속일 수 있다." 이 연구 논문은 야후! 메일, smartsheet.com, 조호, manymoon.com, diigo.com을 포함한 많은 인기 웹사이트가 취약한 것으로 확인되었다고 주장한다. 연구자들은 영향을 받는 당사자들에게 통보했고, 이들은 취약한 코드를 수정했다.

두 번째 문제는 논문에서 "데이터 유형 혼동 논리 결함(Data Type Confusion Logic Flaw)"이라고 명명했으며, 이 역시 공격자가 피해자의 RP 계정에 로그인할 수 있게 한다. 구글과 페이팔이 초기에 취약한 것으로 확인되었다. 오픈아이디는 이 결함에 대한 취약성 보고서를 발표했다. 보고서는 구글과 페이팔이 수정을 적용했으며, 다른 오픈아이디 공급업체들에게도 구현 사항을 확인하도록 권고했다.

피싱

일부 관찰자들은 오픈아이디가 보안 약점을 가지고 있으며 피싱 공격에 취약할 수 있다고 지적했다. 예를 들어, 악의적인 의존 당사자가 최종 사용자를 가짜 아이디 제공자 인증 페이지로 리다이렉트하여 자격 증명을 입력하도록 유도할 수 있다. 이를 완료하면 가짜 인증 페이지를 제어하는 악의적인 당사자가 아이디 제공자의 계정에 액세스할 수 있으며, 해당 최종 사용자의 오픈아이디를 사용하여 다른 서비스에 로그인할 수 있다.

피싱 공격 가능성을 막기 위해 일부 오픈아이디 제공자는 최종 사용자가 의존 당사자와 인증을 시도하기 전에 미리 자신들과 인증을 완료해야 한다는 규정을 두고 있다. 이는 최종 사용자가 아이디 제공자의 정책을 알고 있어야 한다는 점에 의존한다. 2008년 12월, 오픈아이디 재단은 '제공자 인증 정책 확장(PAPE)' 버전 1.0을 승인했다. 이는 "의존 당사자가 사용자를 인증할 때 오픈아이디 제공자가 지정된 인증 정책을 사용하도록 요청하고, 오픈아이디 제공자가 실제로 어떤 정책이 사용되었는지 의존 당사자에게 알릴 수 있게 한다."

개인 정보 보호 및 신뢰 문제

오픈아이디와 관련된 다른 보안 문제로는 개인 정보 보호 부족과 신뢰 문제 해결 실패가 있다. 그러나 이 문제는 오픈아이디만의 것이 아니며 일반적으로 사용되는 인터넷의 현주소일 뿐이다.

하지만 아이디 제공자는 사용자의 오픈아이디 로그인 기록을 가지고 있다. 즉, 사용자가 언제 어떤 웹사이트에 로그인했는지 알고 있어 교차 사이트 추적이 훨씬 쉬워진다. 또한 오픈아이디 계정이 유출되면 단일 사이트 계정이 유출되는 것보다 훨씬 심각한 개인 정보 침해가 발생할 수 있다.

보안되지 않은 연결에서의 인증 하이재킹

또 다른 중요한 취약점은 TLS/SSL이 사용되지 않을 때 인증 방식의 마지막 단계인 아이디 제공자에서 의존 당사자로의 리다이렉트 URL에서 발생한다. 이 리다이렉트의 문제는 (예: 와이어 스니핑을 통해) 이 URL을 얻을 수 있는 누구든지 이를 재생(replay)하여 피해자 사용자인 것처럼 사이트에 로그인할 수 있다는 사실이다. 일부 아이디 제공자는 논스(한 번만 사용되는 숫자)를 사용하여 사용자가 사이트에 한 번 로그인하고 연속적인 모든 시도를 실패하게 한다. 논스 솔루션은 사용자가 URL을 가장 먼저 사용하는 경우에는 작동한다. 그러나 와이어를 스니핑하는 빠른 공격자는 URL을 얻고 즉시 사용자의 TCP 연결을 재설정(공격자가 와이어를 스니핑 중이므로 필요한 TCP 시퀀스 번호를 알고 있음)한 다음 위에서 설명한 재생 공격을 실행할 수 있다. 따라서 논스는 수동적 공격자로부터는 보호하지만, 능동적 공격자가 재생 공격을 실행하는 것을 막을 수는 없다. 인증 과정에서 TLS/SSL을 사용하면 이 위험을 크게 줄일 수 있다.

Covert Redirect

2014년 5월 1일, "OAuth 2.0 및 오픈아이디와 관련된 Covert Redirect"라는 버그가 공개되었다. 이는 싱가포르 난양 이공대학 물리 및 수학 과학부의 박사 과정 학생 왕징(Wang Jing)이 발견했다.

오픈아이디의 발표는 다음과 같다: "2014년 5월에 알려진 'Covert Redirect'는 공격자가 오픈 리다이렉터(open redirector)를 사용하는 사례로, 잘 알려진 위협이며 잘 알려진 예방 수단이 있다. 오픈아이디 커넥트 프로토콜은 이 취약점을 방지하기 위해 오픈 리다이렉터를 배제하는 엄격한 조치를 의무화한다."

"지금까지의 일반적인 의견은 Covert Redirect가 그만큼 나쁘지는 않지만 여전히 위협적이라는 것이다. 무엇이 이를 위험하게 만드는지 이해하려면 오픈 리다이렉트에 대한 기본적인 이해와 이를 악용하는 방법을 알아야 한다."

패치는 즉시 제공되지 않았다. 41st Parameter의 설립자이자 회장 겸 최고 혁신 책임자인 오리 아이젠(Ori Eisen)은 수 마켓 포렘바(Sue Marquette Poremba)에게 "분산 시스템에서 우리는 참여자들이 올바른 일을 할 것이라는 선의를 믿고 있습니다. OAuth와 오픈아이디의 경우 분산이 워낙 광범위하여 모든 웹사이트가 가까운 미래에 패치를 적용할 것이라고 기대하는 것은 불합리합니다"라고 말했다.

역사

원래의 오픈아이디 인증 프로토콜은 2005년 5월 인기 있는 커뮤니티 웹사이트 라이브저널의 창립자이자 식스 아파트에서 근무하던 브래드 피츠패트릭에 의해 개발되었다. 초기에는 YADIS("Yet Another Decentralized Identity Interoperability System"의 약어)로 지칭되었으나, openid.net 도메인 네임이 식스 아파트에 프로젝트용으로 제공된 후 오픈아이디로 명명되었다. 오픈아이디 지원은 곧 라이브저널과 라이브저널 소프트웨어 엔진 커뮤니티인 DeadJournal의 블로그 댓글에 구현되었고 디지털 신원 커뮤니티에서 빠르게 주목을 받았다. 웹 개발자 잔레인(JanRain)은 오픈아이디의 초기 지지자로서 오픈아이디 소프트웨어 라이브러리를 제공하고 오픈아이디 기반 서비스 중심으로 사업을 확장했다.

2005년 6월 말, 오픈아이디 사용자와 전사적 소프트웨어 기업인 NetMesh의 개발자들 사이에 논의가 시작되어 오픈아이디와 NetMesh의 유사한 Light-weight Identity(LID) 프로토콜 간의 상호 운용성에 대한 협력으로 이어졌다. 이 협력의 직접적인 결과는 오픈아이디에 원래 사용되었던 이름을 채택한 야디스 검색 프로토콜이었다. 새로운 야디스는 2005년 10월 24일에 발표되었다. 며칠 후 2005년 인터넷 신원 워크숍(Internet Identity Workshop)에서의 토론 이후, XRI/i-name 개발자들이 야디스 프로젝트에 합류했으며, 프로토콜 활용을 위해 확장 가능 자원 기술자 시퀀스(XRDS) 형식을 기여했다.

12월, Sxip Identity의 개발자들은 단순 확장 가능 신원 프로토콜(SXIP) 버전 2.0의 개발을 LID나 오픈아이디와 같은 URL 기반 신원으로 전환한다고 발표한 후 오픈아이디/야디스 커뮤니티와 논의를 시작했다. 2006년 3월, 잔레인은 기초적인 프로필 교환을 가능하게 하는 오픈아이디용 단순 등록(SREG) 확장을 개발했고, 4월에는 오픈아이디 확장 형식을 공식화하는 제안서를 제출했다. 같은 달, 오픈아이디에 전체 XRI 지원을 통합하는 작업도 시작되었다. 5월 초경, 주요 오픈아이디 개발자인 데이비드 레코돈(David Recordon)은 디지털 신원과 오픈아이디 사양 가이드에 더 집중하기 위해 식스 아파트를 떠나 베리사인에 합류했다. 6월 초까지 SXIP 2.0과 오픈아이디 프로젝트 간의 주요 차이점은 전체 신원 URL 대신 아이디 제공자 URL을 제출함으로써 오픈아이디에서 여러 페르소나를 지원하기로 합의하면서 해결되었다. 이와 함께 확장 및 XRI 지원이 진행됨에 따라 오픈아이디는 본격적인 디지털 신원 프레임워크로 발전했으며, 레코돈은 "우리는 오픈아이디가 식별자, 검색, 인증 및 그 위에 위치하는 메시징 서비스 계층을 포괄하는 프레임워크의 우산이 될 것으로 보며, 이 전체적인 것을 '오픈아이디 2.0'이라고 명명했다"고 선언했다. 7월 말, Sxip은 디지털 신원 교환(DIX) 프로토콜을 오픈아이디로 병합하기 시작했고, 8월에는 오픈아이디 속성 교환(AX) 확장의 초기 초안을 제출했다. 2006년 말, ZDNet의 한 기고문은 사용자, 웹사이트 운영자 및 기업가들을 위해 오픈아이디의 필요성을 주장했다.

2007년 1월 31일, 시만텍은 자사의 Identity Initiative 제품 및 서비스에서 오픈아이디를 지원한다고 발표했다. 일주일 후인 2월 6일, 마이크로소프트는 잔레인, Sxip, 베리사인과 함께 오픈아이디와 마이크로소프트의 윈도우 카드스페이스 디지털 신원 플랫폼 간의 상호 운용성을 위해 협력하겠다고 공동 발표했으며, 특히 오픈아이디를 위한 피싱 방지 인증 솔루션을 개발하는 데 중점을 두었다. 협력의 일환으로 마이크로소프트는 향후 신원 서버 제품에서 오픈아이디를 지원하기로 약속했고, 잔레인, Sxip, 베리사인은 향후 신원 솔루션에서 마이크로소프트의 정보 카드(Information Card) 프로필 지원을 추가하기로 약속했다. 2월 중순, AOL은 모든 AOL 및 AOL 인스턴트 메신저(AIM) 계정에 대해 오픈아이디 제공자 서비스가 작동한다고 발표했다.

5월, 썬 마이크로시스템즈는 오픈아이디 커뮤니티와 협력하기 시작하여 오픈아이디 프로그램을 발표했으며, 또한 오픈아이디 커뮤니티와 무주장 합의를 체결하여 오픈아이디 구현에 대해 자사 특허를 주장하지 않겠다고 약속했다. 6월, 오픈아이디 지도부는 오픈아이디 브랜드와 자산을 관리하기 위해 오리건주에 기반을 둔 공익 법인인 오픈아이디 재단을 설립했다. 같은 달, 독립적인 오픈아이디 유럽 재단이 벨기에에서 조르제티(Snorri Giorgetti)에 의해 설립되었다. 12월 초까지 프로토콜의 주요 기여자들에 의해 무주장 합의가 수집되었고, 최종 오픈아이디 인증 2.0 및 오픈아이디 속성 교환 1.0 사양은 12월 5일에 비준되었다.

2008년 1월 중순, 야후!는 제공자이자 의존 당사자로서 초기 오픈아이디 2.0 지원을 발표했으며, 그달 말에 제공자 서비스를 출시했다. 2월 초, 구글, IBM, 마이크로소프트, 베리사인, 야후!가 기업 이사로 오픈아이디 재단에 합류했다. 5월 초경, 소스포지(SourceForge, Inc.)는 주요 오픈 소스 소프트웨어 개발 웹사이트인 SourceForge.net에 오픈아이디 제공자 및 의존 당사자 지원을 도입했다. 7월 말, 인기 소셜 네트워크 서비스인 마이스페이스가 오픈아이디 제공자로서 지원한다고 발표했다. 10월 말, 구글은 오픈아이디 제공자로서 지원을 시작했고 마이크로소프트는 윈도우 라이브 ID가 오픈아이디를 지원할 것이라고 발표했다. 11월, 잔레인은 웹사이트가 오픈아이디 오픈 소스 라이브러리를 설치, 통합 및 구성할 필요 없이 등록 및 로그인을 위해 오픈아이디를 수락할 수 있도록 하는 무료 호스팅 서비스인 RPX Basic을 발표했다.

2009년 1월, 페이팔이 오픈아이디 재단에 기업 회원으로 가입했고, 2월에는 페이스북이 뒤를 이었다. 오픈아이디 재단은 집행 위원회를 구성하고 돈 티보(Don Thibeau)를 상임 이사로 임명했다. 3월, 마이스페이스는 이전에 발표한 오픈아이디 제공자 서비스를 출시하여 모든 마이스페이스 사용자가 자신의 마이스페이스 URL을 오픈아이디로 사용할 수 있게 했다. 5월, 페이스북은 의존 당사자 기능을 출시하여 사용자가 자동 로그인 지원 오픈아이디 계정(예: 구글)을 사용하여 페이스북에 로그인할 수 있게 했다.

2013년 9월, 잔레인은 MyOpenID.com이 2014년 2월 1일에 폐쇄될 것이라고 발표했다. 원형 차트는 2013년 2분기 기준으로 소셜 로그인 공간을 페이스북과 구글이 장악하고 있음을 보여주었다. 그 이후 페이스북은 오픈아이디를 떠났다. 더 이상 후원사가 아니며, 이사회에 대표를 두고 있지도 않고, 오픈아이디 로그인을 허용하지도 않는다.

2016년 5월, 시만텍은 pip.verisignlabs.com 오픈아이디 개인 신원 포털 서비스 중단을 발표했다.

2018년 3월, 스택 오버플로는 비용을 정당화하기에는 부족한 사용량을 이유로 오픈아이디 지원 종료를 발표했다. 발표에서는 활동을 기반으로 볼 때 사용자들이 페이스북, 구글 및 이메일/비밀번호 기반 계정 인증을 강력히 선호한다고 밝혔다.

OAuth를 사용한 의사 인증(pseudo-authentication) 대 오픈아이디

오픈아이디는 단일 자격 증명 세트를 사용하여 여러 사이트에 액세스하는 방법인 반면, OAuth는 한 사이트가 다른 사이트의 사용자 계정과 관련된 정보에 액세스하고 사용하도록 허가하는 것을 용이하게 한다. OAuth는 인증 프로토콜이 아니지만, 인증 프로토콜의 일부로 사용될 수는 있다.

사용자가 애플리케이션에 액세스하는 컨텍스트에서의 인증은 애플리케이션에 현재 사용자가 누구인지, 그리고 그들이 존재하는지 여부를 알려준다. [...] 인증은 전적으로 사용자와 그들의 애플리케이션 존재에 관한 것이며, 인터넷 규모의 인증 프로토콜은 네트워크 및 보안 경계를 넘어 이 작업을 수행할 수 있어야 한다.

그러나 OAuth는 애플리케이션에 그러한 것을 전혀 알려주지 않는다. OAuth는 사용자에 대해 아무것도 말하지 않으며, 사용자가 어떻게 자신의 존재를 증명했는지 또는 심지어 그들이 여전히 거기에 있는지조차 말하지 않는다. OAuth 클라이언트의 입장에서, 그것은 토큰을 요청했고, 토큰을 받았으며, 결국 그 토큰을 사용하여 일부 API에 액세스했다. 그것은 누가 애플리케이션을 허가했는지, 또는 거기에 사용자가 있는지조차 알지 못한다. 사실, OAuth의 핵심 목적 중 상당수는 사용자가 클라이언트와 액세스되는 리소스 사이의 연결에 존재하지 않는 상황에서 사용할 수 있도록 위임된 액세스를 제공하는 데 있다. 이는 클라이언트 허가에는 훌륭하지만, 사용자가 거기에 있는지 아닌지(그리고 그들이 누구인지)를 파악하는 것이 전부인 인증에는 정말로 나쁘다.

다음 그림은 인증을 위해 오픈아이디와 OAuth를 사용할 때의 차이점을 강조한다. 오픈아이디의 경우 프로세스는 애플리케이션이 사용자에게 신원(일반적으로 오픈아이디 URI)을 묻는 것으로 시작하지만, OAuth의 경우 애플리케이션이 사용자를 대신하여 API에 액세스(집에 들어가기)하기 위해 제한된 액세스 OAuth 토큰(발렛 키)을 직접 요청한다는 점에 주목하라. 사용자가 해당 액세스를 허가할 수 있다면, 애플리케이션은 API를 사용하여 프로필(신원)을 설정하기 위한 고유 식별자를 검색할 수 있다.

오픈아이디 vs. OAuth를 사용한 의사 인증

의사 인증에 대한 공격

오픈아이디는 인증을 위해 OAuth를 오용하는 사용자들에 대한 아래의 공격을 방지하는 암호화 검증 메커니즘을 제공한다.

발렛 키는 사용자를 어떤 식으로도 설명하지 않으며, 단지 (사용자의 것도 아닌, 단지 키를 가지고 있을 뿐인) 어떤 집에 대한 제한된 액세스 권한만을 제공한다는 점에 유의하라. 따라서 키가 유출되면(사용자가 악의적이고 다른 사람의 집 열쇠를 훔치는 데 성공한 경우), 사용자는 자신의 진위 여부를 요청한 애플리케이션에 대해 집주인을 사칭할 수 있다. 신뢰 체인의 어느 시점에서든 키가 유출되면, 악의적인 사용자는 이를 가로채어 동일한 OAuth 인증 서버에 대해 OAuth2를 의사 인증으로 의존하는 모든 애플리케이션에 대해 사용자 X를 사칭하는 데 사용할 수 있다. 반대로, 공증된 편지에는 요청 애플리케이션이 사용자 대조를 통해 확인할 수 있는 사용자의 서명이 포함되어 있으므로 이 공격은 실행 가능하지 않다.

편지 검증

편지는 공개 키 암호 방식을 사용하여 인증될 수 있다.

  • 요청 애플리케이션은 자신의 암호화 공개 키를 사용자에게 제공하고, 사용자는 이를 인증 서버에 제공한다.
  • 인증 서버는 애플리케이션의 공개 키를 사용하여 챌린지-핸드셰이크를 위해 사용자가 알고 있는 비밀의 단방향 해시(예: 암호)에 해당하는 암호화 키가 포함된 문서를 암호화한다.
  • 사용자는 암호화된 문서를 애플리케이션에 다시 전달하고, 애플리케이션은 이를 복호화한다.
  • 애플리케이션은 수신된 암호화 키를 사용하여 임의의 문구를 암호화하고 사용자에게도 동일한 작업을 요청한 다음, 결과를 비교하여 일치하면 사용자가 진본임을 확인한다.

오픈아이디 커넥트(OIDC)

2014년 2월 오픈아이디 재단에 의해 발표된 오픈아이디 커넥트(OIDC)는 3세대 오픈아이디 기술이다. 이는 OAuth 2.0 허가 프레임워크 위에 구축된 인증 계층이다. 컴퓨팅 클라이언트가 허가 서버에서 수행한 인증을 기반으로 최종 사용자의 신원을 확인하고, 상호 운용 가능하며 REST와 유사한 방식으로 최종 사용자에 대한 기본 프로필 정보를 얻을 수 있게 한다. 기술적으로 오픈아이디 커넥트는 JSON을 데이터 형식으로 사용하는 RESTful HTTP API를 지정한다.

오픈아이디 커넥트는 웹 기반, 모바일 및 자바스크립트 클라이언트를 포함한 다양한 당사자가 인증된 세션 및 최종 사용자에 대한 정보를 요청하고 수신할 수 있게 한다. 오픈아이디 커넥트 사양은 확장 가능하며, 신원 데이터 암호화, 오픈아이디 제공자 검색, 세션 관리와 같은 선택적 기능을 지원한다.

같이 보기

각주

  1. 1 2 3 4 Eldon, Eric (2009년 4월 14일). “Single sign-on service OpenID getting more usage”. venturebeat.com. 2018년 4월 2일에 원본 문서에서 보존된 문서. 2009년 4월 25일에 확인함.
  2. ↑ “What is an OpenID?”. 2007년 10월 8일. 2014년 6월 14일에 원본 문서에서 보존된 문서. 2014년 6월 19일에 확인함.
  3. ↑ “OpenID Authentication 2.0 specification – Final”. 2011년 10월 22일에 원본 문서에서 보존된 문서. 2011년 10월 24일에 확인함.
  4. ↑ “OpenID Attribute Exchange 1.0 – Final”. 2017년 11월 20일에 원본 문서에서 보존된 문서. 2011년 10월 24일에 확인함.
  5. ↑ “OpenID Authentication 2.0 - Final”. 2007년 12월 5일. 2011년 10월 22일에 원본 문서에서 보존된 문서. 2014년 5월 18일에 확인함.
  6. ↑ “OpenID Usage Statistics”. 2016년 4월 4일에 원본 문서에서 보존된 문서. 2016년 4월 1일에 확인함.
  7. ↑ bashburn, bill (2008년 4월 22일). “BBC Joins OpenID Foundation”. 《OpenID - The Internet Identity Layer》. 2008년 10월 16일에 원본 문서에서 보존된 문서. 2008년 10월 29일에 확인함.
  8. ↑ “Technology Leaders Join OpenID Foundation to Promote Open Identity Management on the Web”. 2008년 2월 7일. 2008년 2월 10일에 원본 문서에서 보존된 문서.
  9. ↑ “PayPal Access Uses OpenID 2.0”. 《OpenID - The Internet Identity Layer》. OpenID ·. 2011년 10월 19일. 2014년 6월 22일에 원본 문서에서 보존된 문서. 2014년 6월 19일에 확인함.
  10. ↑ “Steam Community :: Steam Web API Documentation”. 2012년 2월 10일에 원본 문서에서 보존된 문서. 2012년 2월 10일에 확인함.
  11. ↑ Perez, Juan Carlos (2008년 12월 4일). “Facebook, Google launch data portability programs to all”. Network World, Inc. 2014년 6월 22일에 원본 문서에서 보존된 문서. 2014년 6월 19일에 확인함.
  12. ↑ “It's spring cleaning time for Blogger”. Blogger team. 2018년 8월 2일에 원본 문서에서 보존된 문서. 2019년 9월 10일에 확인함.
  13. ↑ Deeptha, R.; Mukesh, Rajeswari (2018년 9월 1일). “Extending OpenID Connect Towards Mission Critical Applications” (영어). 《Cybernetics and Information Technologies》 18 (3): 93–110. doi:10.2478/cait-2018-0041.
  14. ↑ “OpenID Authentication 1.1#Delegation”. 2017년 11월 18일에 원본 문서에서 보존된 문서. 2009년 6월 30일에 확인함.
  15. ↑ Paul Tarjan. “Easy OpenID Delegation with Yadis”. 2009년 7월 4일에 원본 문서에서 보존된 문서. 2009년 6월 30일에 확인함.
  16. 1 2 “Leadership”. openID Foundation. 2014년 6월 24일에 원본 문서에서 보존된 문서. 2014년 6월 19일에 확인함.
  17. ↑ “Trademark Assignment, Serial #: 78899244”. 미국 특허청. 2008년 5월 6일. 2013년 10월 10일에 원본 문서에서 보존된 문서. 2008년 5월 19일에 확인함. Exec Dt: 03/27/2008
  18. ↑ “Latest Status Info”. 미국 특허청. 2006년 3월 27일. 2011년 5월 14일에 원본 문서에서 보존된 문서. 2008년 3월 20일에 확인함.
  19. ↑ “NetMesh: Company / Management”. 《NetMesh》. 2007년 8월 30일에 원본 문서에서 보존된 문서. 2008년 3월 20일에 확인함.
  20. ↑ “OpenID Europe Trademark & Logo Policy”. 《OpenID Europe Foundation》. 2008년 3월 9일에 원본 문서에서 보존된 문서. 2008년 3월 20일에 확인함.
  21. ↑ Reddig, Randy (2005년 6월 29일). “OpenID Logo”. 《Danga Interactive》. 2008년 2월 14일에 원본 문서에서 보존된 문서. 2008년 3월 20일에 확인함.
  22. ↑ Fitzpatrick, Brad (2009년 8월 10일). “Intellectual Property”. 2009년 10월 11일에 원본 문서에서 보존된 문서. 2009년 10월 13일에 확인함.
  23. 1 2 “Sun OpenID: Non-Assertion Covenant”. 《썬 마이크로시스템즈》. 2008년 3월 20일에 확인함.
  24. ↑ “VeriSign's OpenID Non-Assertion Patent Covenant”. 《베리사인》. 2008년 4월 15일에 원본 문서에서 보존된 문서. 2008년 3월 20일에 확인함.
  25. ↑ Rui Wang; Shuo Chen; XiaoFeng Wang (May 2012). “Signing Me onto Your Accounts through Facebook and Google: a Traffic-Guided Security Study of Commercially Deployed Single-Sign-On Web Services”. 2016년 4월 13일에 원본 문서에서 보존된 문서. 2012년 3월 9일에 확인함.
  26. ↑ “Attribute Exchange Security Alert”. 2011년 5월 5일. 2017년 7월 31일에 원본 문서에서 보존된 문서. 2012년 3월 9일에 확인함.
  27. ↑ “Security advisory to websites using OpenID Attribute Exchange”. 2011년 5월 5일. 2011년 12월 24일에 원본 문서에서 보존된 문서. 2012년 3월 9일에 확인함.
  28. ↑ “Vulnerability report: Data confusion”. 《OpenID - The Internet Identity Layer》. 2012년 3월 15일. 2019년 9월 5일에 원본 문서에서 보존된 문서. 2012년 3월 15일에 확인함.
  29. ↑ Crowley, Paul (2005년 6월 1일). “Phishing attacks on OpenID”. 《Danga Interactive》. 2008년 10월 10일에 원본 문서에서 보존된 문서. 2008년 3월 20일에 확인함.
  30. ↑ Anderson, Tim (2007년 3월 5일). “OpenID still open to abuse”. IT Week. 2008년 7월 4일에 원본 문서에서 보존된 문서. 2007년 3월 13일에 확인함.
  31. ↑ Slot, Marco. “Beginner's guide to OpenID phishing”. 2007년 8월 4일에 원본 문서에서 보존된 문서. 2007년 7월 31일에 확인함.
  32. ↑ “Verisign PIP FAQ”. 2008년 11월 13일에 원본 문서에서 보존된 문서. 2008년 11월 13일에 확인함.
  33. ↑ Jones, Mike (2008년 12월 31일). “PAPE Approved as an OpenID Specification”. OpenID Foundation. 2009년 1월 1일에 원본 문서에서 보존된 문서. 2009년 1월 2일에 확인함.
  34. ↑ Stefan Brands (2007년 8월 22일). “The problem(s) with OpenID”. 2011년 5월 16일에 원본 문서에서 보존된 문서. 2010년 12월 12일에 확인함. (원래 The Identity Corner의 www.idcorner.org/?p=161에 게시됨)
  35. ↑ Tsyrklevich, Eugene. “Single Sign-On for the Internet: A Security Story” (PDF). Blackhat USA. 2012년 1월 12일에 원본 문서 (PDF)에서 보존된 문서. 2012년 4월 19일에 확인함.
  36. ↑ “Serious security flaw in OAuth, OpenID discovered”. CNET. 2014년 5월 2일. 2015년 11월 2일에 원본 문서에서 보존된 문서. 2014년 11월 10일에 확인함.
  37. ↑ “Covert Redirect”. Tetraph. 2014년 5월 1일. 2016년 3월 10일에 원본 문서에서 보존된 문서. 2014년 11월 10일에 확인함.
  38. ↑ “Facebook, Google Users Threatened by New Security Flaw”. Yahoo. 2014년 5월 2일. 2019년 7월 25일에 원본 문서에서 보존된 문서. 2014년 11월 10일에 확인함.
  39. ↑ “Nasty Covert Redirect Vulnerability found in OAuth and OpenID”. The Hacker News. 2014년 5월 3일. 2014년 11월 8일에 원본 문서에서 보존된 문서. 2014년 11월 10일에 확인함.
  40. ↑ “Math student detects OAuth, OpenID security vulnerability”. Tech Xplore. 2014년 5월 3일. 2014년 12월 4일에 원본 문서에서 보존된 문서. 2014년 11월 10일에 확인함.
  41. ↑ “Covert Redirect”. 《OpenID - The Internet Identity Layer》. OpenID. 2014년 5월 15일. 2014년 10월 20일에 원본 문서에서 보존된 문서. 2014년 11월 10일에 확인함.
  42. ↑ “'Covert Redirect' vulnerability impacts OAuth 2.0, OpenID”. SC Magazine. 2014년 5월 2일. 2014년 11월 10일에 확인함.
  43. ↑ “Lessons to be Learned from Covert Redirect”. 41st Parameter. 2014년 5월 5일. 2014년 11월 10일에 확인함.
  44. ↑ Fitzpatrick, Brad (2005년 5월 16일). “Distributed Identity: Yadis”. 《라이브저널》. 2006년 5월 4일에 원본 문서에서 보존된 문서. 2008년 3월 20일에 확인함.
  45. ↑ Waters, John K (2007년 12월 1일). “OpenID Updates Identity Spec”. 《Redmond Developer News》. 2008년 2월 8일에 원본 문서에서 보존된 문서. 2008년 3월 20일에 확인함.
  46. ↑ “YADIS – Yet Another Decentralized Identity Interoperability System” (PDF). 《The YADIS Project》.
  47. ↑ “Main Page - YADIS” (영어). 《yadis.org》. 2005년 11월 25일에 원본 문서에서 보존된 문서. 2026년 7월 26일에 확인함.
  48. ↑ WO2010075761A1, 孙谦; 胡立新 & 谭东晖, "一种向访问用户提供资源的方法、服务器和系统", issued 2010-07-08
  49. ↑ Lehn, David I. (2005년 5월 18일). “18 May 2005”. 《Advogato blog for dlehn》. Advogato. 2010년 12월 21일에 원본 문서에서 보존된 문서. 2009년 10월 13일에 확인함. They were looking for a name and managed to email me about openid.net right before I was going to offer it to them. So I gave it to them for the new and improved OpenID project.
  50. ↑ “OpenID: an actually distributed identity system”. 2005년 9월 24일. 2005년 9월 24일에 원본 문서에서 보존된 문서. 2008년 3월 20일에 확인함.
  51. 1 2 Fitzpatrick, Brad (2006년 5월 30일). “brad's life – OpenID and SixApart”. 《라이브저널》. 2007년 4월 25일에 원본 문서에서 보존된 문서. 2008년 3월 20일에 확인함.
  52. ↑ Recordon, David (2005년 12월 24일). “Announcing YADIS...again”. 《Danga Interactive》. 2008년 9월 5일에 원본 문서에서 보존된 문서. 2008년 3월 20일에 확인함.
  53. ↑ Reed, Dummond (2005년 12월 31일). “Implementing YADIS with no new software”. 《Danga Interactive》. 2008년 9월 5일에 원본 문서에서 보존된 문서. 2008년 3월 20일에 확인함.
  54. ↑ Reed, Drummond (2008년 11월 30일). “XRD Begins”. 《Equals Drummond》. 2008년 12월 20일에 원본 문서에서 보존된 문서. 2009년 1월 5일에 확인함.
  55. ↑ Hardt, Dick (2005년 12월 18일). “Sxip concerns with YADIS”. 《Danga Interactive》. 2008년 10월 15일에 원본 문서에서 보존된 문서. 2008년 3월 20일에 확인함.
  56. ↑ Hardt, Dick (2005년 12월 10일). “SXIP 2.0 Teaser”. 《Identity 2.0》. 2007년 8월 14일에 원본 문서에서 보존된 문서. 2008년 3월 20일에 확인함.
  57. ↑ Hoyt, Josh (2006년 3월 15일). “OpenID + Simple Registration Information Exchange”. 《Danga Interactive》. 2008년 10월 11일에 원본 문서에서 보존된 문서. 2008년 3월 20일에 확인함.
  58. ↑ Grey, Victor (2006년 4월 2일). “Proposal for an XRI (i-name) profile for OpenID”. 《Danga Interactive》. 2008년 3월 19일에 원본 문서에서 보존된 문서. 2008년 3월 20일에 확인함.
  59. ↑ Recordon, David (2006년 4월 29일). “Movin' On....”. 《라이브저널》. 2006년 10월 20일에 원본 문서에서 보존된 문서. 2008년 3월 20일에 확인함.
  60. ↑ Recordon, David (2006년 6월 16일). “Moving OpenID Forward”. 《Danga Interactive》. 2008년 5월 22일에 원본 문서에서 보존된 문서. 2008년 5월 19일에 확인함.
  61. ↑ Becker, Phil (2006년 12월 4일). “The case for OpenID”. 《ZDNet》. 2025년 5월 4일에 원본 문서에서 보존된 문서. 2010년 12월 12일에 확인함.
  62. ↑ “Symantec Unveils Security 2.0 Identity Initiative at DEMO 07 Conference”. 《시만텍》. 2007년 1월 31일. 2007년 2월 9일에 원본 문서에서 보존된 문서. 2008년 3월 20일에 확인함.
  63. ↑ Graves, Michael (2007년 2월 6일). “VeriSign, Microsoft & Partners to Work together on OpenID + Cardspace”. 《베리사인》. 2008년 5월 3일에 원본 문서에서 보존된 문서. 2008년 3월 20일에 확인함.
  64. ↑ Panzer, John (2007년 2월 16일). “AOL and 63 Million OpenIDs”. 《AOL 개발자 네트워크》. 2008년 5월 11일에 원본 문서에서 보존된 문서. 2008년 3월 20일에 확인함.
  65. ↑ “Sun Microsystems Announces OpenID Program”. 《PR 뉴스와이어》. 2007년 5월 7일. 2008년 5월 9일에 원본 문서에서 보존된 문서. 2008년 3월 20일에 확인함.
  66. ↑ 오픈아이디 이사회 (2007년 6월 1일). “OpenID Foundation”. 2017년 11월 23일에 원본 문서에서 보존된 문서. 2008년 3월 20일에 확인함.
  67. ↑ “OpenID Europe Foundation”. 2008년 4월 15일에 원본 문서에서 보존된 문서. 2008년 4월 4일에 확인함.
  68. ↑ “OpenID 2.0...Final(ly)!”. 《오픈아이디 재단》. 2007년 12월 5일. 2008년 4월 30일에 원본 문서에서 보존된 문서. 2008년 3월 20일에 확인함.
  69. ↑ “Yahoo! Announces Support for OpenID; Users Able to Access Multiple Internet Sites with Their Yahoo! ID”. 《야후!》. 2008년 1월 17일. 2008년 3월 4일에 원본 문서에서 보존된 문서. 2008년 3월 20일에 확인함.
  70. ↑ “Technology Leaders Join OpenID Foundation to Promote Open Identity Management on the Web”. 《오픈아이디 재단》 (Marketwire). 2008년 2월 7일. 2008년 2월 15일에 원본 문서에서 보존된 문서. 2008년 3월 20일에 확인함.
  71. ↑ “SourceForge Implements OpenID Technology” (보도자료). SourceForge, Inc. 2008년 5월 7일. 2008년 5월 13일에 원본 문서에서 보존된 문서. 2008년 5월 21일에 확인함.
  72. ↑ “MySpace Announces Support for "OpenID" and Introduces New Data Availability Implementations”. 《Business Wire》. 마이스페이스. 2008년 7월 22일. 2쪽. 2011년 5월 14일에 원본 문서에서 보존된 문서. 2008년 7월 23일에 확인함.
  73. ↑ “Microsoft and Google announce OpenID support”. 《OpenID - The Internet Identity Layer》. 오픈아이디 재단. 2008년 10월 30일. 2008년 12월 18일에 원본 문서에서 보존된 문서. 2009년 1월 2일에 확인함.
  74. ↑ “JanRain Releases Free Version of Industry Leading OpenID Solution” (보도자료). JanRain, Inc. 2008년 11월 14일. 2008년 12월 18일에 원본 문서에서 보존된 문서. 2008년 11월 14일에 확인함.
  75. ↑ “Facebook Developers | Facebook Developers News”. Developers.facebook.com. 2009년 5월 18일. 2009년 12월 23일에 원본 문서에서 보존된 문서. 2009년 7월 28일에 확인함.
  76. ↑ “Facebook now accepts Google account logins”. Pocket-lint.com. 2009년 5월 19일. 2009년 5월 22일에 원본 문서에서 보존된 문서. 2009년 7월 28일에 확인함.
  77. ↑ “OpenID Requirements – Facebook Developer Wiki”. Wiki.developers.facebook.com. 2009년 6월 26일. 2009년 12월 23일에 원본 문서에서 보존된 문서. 2009년 7월 28일에 확인함.
  78. ↑ Kane, Zee M (2013년 9월 4일). “MyOpenID to shut down. Will be turned off on February 1, 2014”. 《The Next Web》. 2013년 9월 7일에 원본 문서에서 보존된 문서. 2013년 9월 5일에 확인함.
  79. ↑ “OpenID Sponsoring Members”. 2009년 10월 7일. 2014년 4월 17일에 확인함.
  80. ↑ “Symantec Personal Identification Portal banner indicates service will be discontinued on 12 September 2016”. 2016년 6월 11일에 원본 문서에서 보존된 문서. 2016년 5월 17일에 확인함.
  81. ↑ “Is Symantec failing hard at being Google?”. 2016년 5월 7일. 2016년 6월 2일에 원본 문서에서 보존된 문서. 2016년 5월 17일에 확인함.
  82. ↑ “Support for OpenID ended on July 25, 2018”. 2018년 3월 7일에 원본 문서에서 보존된 문서. 2018년 3월 6일에 확인함.
  83. ↑ “User Authentication with OAuth 2.0”. 《OAuth.net》. 2015년 11월 19일에 원본 문서에서 보존된 문서. 2015년 3월 19일에 확인함.
  84. ↑ “Why is it a bad idea to use plain oauth2 for authentication?”. 《Information Security Stack Exchange》. 2018년 7월 7일에 원본 문서에서 보존된 문서. 2018년 7월 7일에 확인함.
  85. ↑ “Final OpenID Connect Core 1.0 - Appendix C. Notices”. 2014. 2024년 3월 14일에 원본 문서에서 보존된 문서. 2024년 3월 14일에 확인함.
  86. ↑ “OpenID Connect FAQ and Q&As”. 2014년 2월 20일. 2014년 8월 23일에 원본 문서에서 보존된 문서. 2014년 8월 25일에 확인함.

외부 링크