OpenID

From Wikipedia, the free encyclopedia

You have new messages (last change).
The OpenID logo
Enlarge
The OpenID logo

OpenID is a decentralized digital identity system, in which any user's online identity is given by URL (such as for a blog or a home page) or an XRI in the latest version, and can be verified by any server running the protocol.

On OpenID-enabled sites, Internet users don't need to create and manage a new account for every site before being granted access. Instead, they only need to be able to authenticate with a trusted site that supports OpenID, called the identity provider (or IdP, sometimes called an i-broker). The identity provider can then confirm ownership of the user's OpenID identifier to other OpenID-enabled sites, called relying parties or RPs. Unlike most single sign-on architectures, OpenID does not specify the authentication mechanism. Therefore, the strength of an OpenID login depends on how much a relying party knows about the authentication policies of the identity provider. Without such knowledge, OpenID is not meant to be used on sensitive accounts (banking, e-commerce transactions, etc.), but if an identity provider uses strong authentication, OpenID can be used for all types of transactions.

OpenID is increasingly gaining adoption amongst large sites, with organizations like Wikipedia and Technorati announcing that they will support OpenID.

Contents

[edit] Development

The OpenID system was originally developed by Brad Fitzpatrick of LiveJournal, though David Recordon of VeriSign, Josh Hoyt of JanRain, and Dick Hardt of Sxip are now co-authors. Future OpenID specifications are being developed in a meritocratic fashion on specs@openid.net. To help spawn additional deployment, a group of vendors announced a $50,000 USD developer bounty program in August of 2006, offering $5,000 USD each to the first ten large-scale Open Source projects to implement OpenID support.[1]

Starting with version 1.1, OpenID uses the Yadis service discovery protocol. Currently work is underway developing OpenID Authentication 2.0, though OpenID is now developing into a much more complete framework that will support other identity services besides authentication.

[edit] Terminology

A basic glossary of the terms used with OpenID:

  • end user — The person who wants to assert his identity to a site.
  • identifier — The URL or XRI chosen by the End User as their OpenID identifier.
  • identity provider — A service provider offering the service of registering OpenID URLs or XRIs and providing OpenID authentication (and possibly other identity services).
  • relying party — The site that wants to verify the end user's identifier.
  • server or server-agent — The server that verifies the end user's identifier. This may be the end user's own server (such as their blog), or a server operated by an identity provider.
  • user-agent — The program (such as a browser) that the end user is using to access an identity provider or a relying party.

[edit] How OpenID works

A website, such as example.com, which wants to enable OpenID logins for its visitors places a login form somewhere on the page. Unlike a typical login form, which prompts the user for a user name and password, there is only one field - for the OpenID identifier. The site may choose to display a small OpenID logo next to the field. This form is connected to an implementation of an OpenID client library.

If a user named Alice wants to log in to example.com using the OpenID identifier alice.openid-provider.org that she has registered with the identity provider openid-provider.org, she simply goes to example.com and types alice.openid-provider.org in the OpenID login box. Starting with OpenID Authentication 2.0 (and supported in some OpenID 1.1 implementations), Alice could also login by typing an i-name such as =example.alice or =example.community*alice.

If the identifier is a URL, the first thing the relying party (example.com) does is transform into a canonical form, e.g., http://alice.openid-provider.org/. With OpenID 1.0, the relying party then requests the web page located at that URL and, via an HTML link tag, discovers that the provider server is, say, http://openid-provider.org/openid-auth.php. It also discovers whether or not it should use a delegated identity (see below). Starting with OpenID 1.1, the client does discovery by requesting the XRDS document (also called the Yadis document) with the content type application/xrds+xml that may be available at the target URL and is always available for a target XRI.

There are two modes in which the relying party can communicate with the identity provider:

  • checkid_immediate, which is machine-oriented and in which all communication between the two servers is done is the background, without the user's knowledge;
  • checkid_setup, in which the user communicates with the provider server directly using the very same web browser used to access the relying party site.

The second option is more popular on the Web; also, checkid_immediate can fallback to checkid_setup if the operation cannot be automated.

First, the relying party and the provider (optionally) establish a shared secret - an associate handle, which the relying party then stores. If using checkid_setup, the relying party redirects the user's web browser to the provider. In this case, Alice's browser is redirected to openid-provider.org so Alice can authenticate herself with the provider.

The method of authentication may vary, but typically, an OpenID provider asks for a password (and then possibly stores the user's session using cookies, as many websites with password-based authentication do). Alice may be prompted for her password if she was not logged in on openid-provider.org, and then asked whether she trusts, say, http://example.com/openid-return.php - the page designated by example.com as the one where the user should return after completing authentication - to receive details about her identity. If she answers positively, OpenID authentication is considered successful and the browser is redirected to the designated return page with credentials given. If Alice decides not to trust the relying party site, the browser is still redirected - however, the relying party is notified that its request was rejected, so example.com refuses to authenticate Alice in turn.

However, the login process is not over yet because at this stage, example.com cannot decide whether the credentials received really came from openid-provider.org. If they had previously established a shared secret (see above), the consumer can validate the shared secret received with the credentials against the one previously stored. Such a consumer is called stateful because it stores the shared secret between sessions. In comparison, a stateless or dumb consumer must make one more background request (check_authentication) to ensure that the data indeed came from openid-provider.org.

After Alice's identifier has been verified, she is considered logged in to example.com as alice.openid-provider.org. The site may then store the session or, if this is her first logon, prompt Alice to enter some information specific to example.com, in order to complete registration.

[edit] OpenID identifiers

Starting with OpenID Authentication 2.0 (and some 1.1 implementations), there are two types of identifiers that can be used with OpenID: URLs and XRIs.

[edit] URLs

There are two ways to obtain an OpenID-enabled URL that can be used to login on all OpenID-enabled websites.

  1. First, to use an existing URL that you control (such as your blog or home page), and if you know how to edit HTML, you can insert the appropriate OpenID tags in the HTML code following instructions at the OpenID specification. Note that using a subdomain can make your OpenID more memorable and quicker to write, but this is not required.
  2. The second option is to register an OpenID identifier with an identity provider. They offer the ability to register a URL (typically a third-level domain) that will automatically be configured with OpenID authentication service.

[edit] 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 (like domain names), 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 (the CanonicalID element of the XRDS document). 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 user's OpenID identity ever being taken over by another party as can happen with a URL based on a reassignable DNS name.

See i-name for more about registration and resolution of XRIs.

[edit] See also

[edit] References

  1. ^ I Want My OpenID community marketing site, including public bounty program (see bounty sponsors)

[edit] External links

Retrieved from "http://en.wikipedia.org../../../o/p/e/OpenID_10d8.html"