OpenID


OpenID is an open standard and decentralized authentication protocol promoted by the non-profit OpenID Foundation. It allows users to be authenticated by co-operating sites using a third-party identity provider service, eliminating the need for webmasters to provide their own ad hoc login systems, and allowing users to log in to multiple unrelated websites without having to have a separate identity and password for each. Users create accounts by selecting an OpenID identity provider, and then use those accounts to sign on to any website that accepts OpenID authentication. Several large organizations either issue or accept OpenIDs on their websites.
The OpenID standard provides a framework for the communication that must take place between the identity provider and the OpenID acceptor. An extension to the standard facilitates the transfer of user attributes, such as name and gender, from the OpenID identity provider to the relying party. The OpenID protocol does not rely on a central authority to authenticate a user's identity. Moreover, neither services nor the OpenID standard may mandate a specific means by which to authenticate users, allowing for approaches ranging from the common to the novel.
The final version of OpenID is OpenID 2.0, finalized and published in December 2007. The term OpenID may also refer to an identifier as specified in the OpenID standard; these identifiers take the form of a unique Uniform Resource Identifier, and are managed by some "OpenID provider" that handles authentication.

Adoption

, there are over 1 billion OpenID-enabled accounts on the Internet and approximately 1,100,934 sites have integrated OpenID consumer support: AOL, Flickr, Google, Amazon.com, Canonical, LiveJournal, Microsoft, Mixi, Myspace, Novell, OpenStreetMap, Orange, Sears, Sun, Telecom Italia, Universal Music Group, VeriSign, WordPress, Yahoo!, the BBC, IBM, PayPal, and Steam, although some of those organizations also have their own authentication management.
Facebook did use OpenID in the past, but moved to Facebook Connect. Blogger also used OpenID, but since May 2018 no longer supports it.

Technical overview

OpenID is a decentralized authentication protocol that allows users to authenticate with multiple websites using a single set of credentials, eliminating the need for separate usernames and passwords for each website. OpenID authenticates a user with an identity provider, who then provides the user with a unique identifier. This identifier can then be used to authenticate the user with any website that supports OpenID.
When a user visits a website that supports OpenID authentication, the website will redirect the user to their chosen IdP. The IdP will then prompt the user to authenticate themselves. Once the user is authenticated, the IdP will generate an OpenID and send it back to the website. The website can then use this OpenID to authenticate the user without needing to know their actual credentials.
OpenID is built on top of several existing standards, including HTTP, HTML, and XML. OpenID relies on a number of technologies, including a discovery mechanism that allows websites to find the IdP associated with a particular OpenID, as well as security mechanisms to protect against phishing and other attacks.
One of the key benefits of OpenID is that it allows users to control their own identity information, rather than relying on individual websites to store and manage their login credentials. This can be particularly important in cases where websites are vulnerable to security breaches or where users are concerned about the privacy of their personal information.
OpenID has been widely adopted by a number of large websites and service providers, including Google, Yahoo!, and PayPal. The protocol is also used by a number of open source projects and frameworks, including Ruby on Rails and Django.

Logging in

The end user interacts with a relying party that provides an option to specify an OpenID for the purposes of authentication; an end user typically has previously registered an OpenID with an OpenID provider.
The relying party typically transforms the OpenID into a canonical URL form.
  • With OpenID 1.0, the relying party then requests the HTML resource identified by the URL and reads an HTML link tag to discover the OpenID provider's URL. The relying party also discovers whether to use a delegated identity.
  • With OpenID 2.0, the relying party discovers the OpenID provider URL by requesting the XRDS document with the content type application/xrds+xml; this document may be available at the target URL and is always available for a target XRI.
There are two modes in which the relying party may communicate with the OpenID provider:
  • checkid_immediate, in which the relying party requests that the OpenID provider not interact with the end user. All communication is relayed through the end user's user-agent without explicitly notifying the end user.
  • checkid_setup, in which the end user communicates with the OpenID provider via the same user-agent used to access the relying party.
The checkid_immediate mode can fall back to the checkid_setup mode if the operation cannot be automated.
First, the relying party and the OpenID provider establish a shared secret, referenced by an associate handle, which the relying party then stores. If using the checkid_setup mode, the relying party redirects the end user's user-agent to the OpenID provider so the end user can authenticate directly with the OpenID provider.
The method of authentication may vary, but typically, an OpenID provider prompts the end user for a password or some cryptographic token, and then asks whether the end user trusts the relying party to receive the necessary identity details.
If the end user declines the OpenID provider's request to trust the relying party, then the user-agent is redirected back to the relying party with a message indicating that authentication was rejected; the relying party in turn refuses to authenticate the end user.
If the end user accepts the OpenID provider's request to trust the relying party, then the user-agent is redirected back to the relying party along with the end user's credentials. That relying party must then confirm that the credentials really came from the OpenID provider. If the relying party and OpenID provider had previously established a shared secret, then the relying party can validate the identity of the OpenID provider by comparing its copy of the shared secret against the one received along with the end user's credentials; such a relying party is called stateful because it stores the shared secret between sessions. In contrast, a stateless or dumb relying party must make one more background request to ensure that the data indeed came from the OpenID provider.
After the OpenID has been verified, authentication is considered successful and the end user is considered logged into the relying party under the identity specified by the given OpenID. The relying party typically then stores the end user's OpenID along with the end user's other session information.

Identifiers

To obtain an OpenID-enabled URL that can be used to log into OpenID-enabled websites, a user registers an OpenID identifier with an identity provider. Identity providers offer the ability to register a URL that will automatically be configured with OpenID authentication service.
Once they have registered an OpenID, a user can also use an existing URL under their own control as an alias or "delegated identity". They simply insert the appropriate OpenID tags in the HTML or serve a Yadis document.
Starting with OpenID Authentication 2.0, there are two types of identifiers that can be used with OpenID: URLs and XRIs.
XRIs are a new form of Internet identifier designed specifically for cross-domain digital identity. For example, XRIs come in two forms—i-names and i-numbers—that are usually registered simultaneously as synonyms. I-names are reassignable, while i-numbers are never reassigned. When an XRI i-name is used as an OpenID identifier, it is immediately resolved to the synonymous i-number. This i-number is the OpenID identifier stored by the relying party. In this way, both the user and the relying party are protected from the end user's OpenID identity ever being taken over by another party as can happen with a URL based on a reassignable DNS name.

OpenID Foundation

The OpenID Foundation promotes and enhances the OpenID community and technologies. The OIDF is a non-profit international standards development organization of individual developers, government agencies and companies who wish to promote and protect OpenID. The OpenID Foundation was formed in June 2007 and serves as a public trust organization representing an open community of developers, vendors and users. OIDF assists the community by providing needed infrastructure and help in promoting and supporting adoption of OpenID. This includes managing intellectual property and trade marks as well a fostering viral growth and global participation in OpenID.

People

The OpenID Foundation's board of directors has six community board members and eight corporate board members:
Community board members
  • Chairman: Nat Sakimura
  • Vice Chairman: Bjorn Hjelm
  • Treasurer: John Bradley
  • Secretary: Mike Jones
  • Community Representative: George Fletcher
  • Corporate Representative: Ashish Jain
Corporate board members
  • Cisco – Nancy Cam-Winget
  • Google – Filip Verley
  • KDDI – Kosuke Koiwai
  • NRI Secure – Takehisa Shibata
  • Okta – Vittorio Bertocci
  • Ping Identity – Wesley Dunnington
  • Visa Inc. – Luis DaSilva
  • Yahoo Ad Tech – Arvind Kumar Garg

    Chapters

OIDF is a global organization to promote digital identity and to encourage the further adoption of OpenID, the OIDF has encouraged the creation of member chapters. Member chapters are officially part of the Foundation and work within their own constituency to support the development and adoption of OpenID as a framework for user-centric identity on the internet.