From BC$ MobileTV Wiki
Jump to: navigation, search
250px-OpenID logo svg.png

OpenID is a decentralized Single Sign-On system. Using OpenID-enabled sites, web users do not need to remember traditional authentication tokens such as username and password. Instead, they only need to be previously registered on a website with an OpenID "identity provider" (IdP). Since OpenID is decentralized, any website can employ OpenID software as a way for users to sign in; OpenID solves the problem without relying on any centralized website to confirm digital identity.

OpenID is increasingly gaining adoption among large sites, with organizations like Google, Microsoft, IBM, Verisign, Yahoo!, AOL and | Orange acting as providers. In addition, integrated OpenID support has been made a high priority in Firefox 3[1] and OpenID can be used with Windows CardSpace.


OpenID was originally developed by Brad Fitzpatrick of LiveJournal. It was not clear at the time that Fitzpatrick's technology was going to prevail as a standard, however, as multiple competing and technically sound alternatives were also being implemented simultaneously. Through a series of important face-to-face meetings, developers and stakeholders created a common, interoperable standard now called OpenID. Some primary players are, in no particular order, the Lightweight ID, Yadis, "Sxip DIX" protocol that was proposed at IETF, and XRI/"i-name". Future OpenIDspecifications are being developed in a "meritocratic fashion" on, involving many technology companies, user companies and OSS developers.

To help spawn additional deployment, a group of vendors announced a US$50,000 developer bounty program in August 2006, offering $5,000 each to the first ten large-scale Open Source projects to implement OpenID support.[2]

Currently work is underway developing OpenID Authentication 2.0, which will use the Yadis service discovery protocol. OpenID is now developing into a much more complete framework that will support other identity services besides authentication.

Using OpenID

A basic glossary of the terms used with OpenID:

  • End user : The person who wants to assert his or her identity to a site.
  • Identifier : The URL or XRI chosen by the End User as their OpenID identifier.
  • Identity provider or OpenID provider : A service provider offering the service of registering OpenID URLs or XRIs and providing OpenID authentication (and possibly other identity services). Note that the OpenID specifications use the term "OpenID provider" or "OP".
  • 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.
  • Consumer : An obsolete term for the relying party.

Logging in

A website, such as, 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 using the OpenID identifier that she has registered with the identity provider, she simply goes to and types in the OpenID login box.

If the identifier is a URL, the first thing the relying party ( does is transform this URL into a canonical form, e.g., 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, It also discovers whether it should use a delegated identity (see below). Starting with OpenID 2.0, 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 the relying party requests that the provider not interact with the user. All communication is relayed through the user's browser, but presumably 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"f - referenced by 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 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, and then asked whether she trusts, say, - the page designated by 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 refuses to authenticate Alice in turn.

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

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

OpenID does not provide its own form of authentication, but if an identity provider uses "strong authentication", OpenID can be used for secure transactions such as banking and E-commerce.


The "OpenBanking" sub-project of OpenID aims to provide a "more secure way for consumers & small businesses to share financial information & fintech companies to offer innovative banking & payment products/services".


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.

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

  1. To use an existing URL under one's own control (such as one's blog or home page), and if one knows how to edit HTML, one can insert the appropriate OpenID tags in the HTML code following instructions at the OpenID specification.
  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.

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.

OpenID Connect

OpenID Connect (commonly abbreviated as OIDC) is a specification for data sharing and Single Sign-On (SSO) that is commonly paired with OAuth 2.0+ for sharing JWT user "claims" to pair OpenID as an authentication mechanism to OAuth as an "authorization" mechanism.


As of July 2007, there are over 120 million OpenIDs on the Internet (see below) and approximately 4,500 sites have integrated OpenID consumer support.[3]

  • AOL provides (brokers) OpenIDs, in the form "".
  • Orange offers OpenIDs to their 40 million broadband subscribers.
  • SixApart blogging hosts LiveJournal and Vox. Both support OpenID; Vox as a provider and LiveJournal as both a provider and a relying party.
  • [ | WordPress] also provides OpenIDs on all Blog instances
  • Other services accepting OpenID as an alternative to registration include Wikitravel, photo sharing host Zooomr, linkmarking host Ma.gnolia, identity aggregator ClaimID, icon provider IconBuffet, and Basecamp and Highrise by 37signals.
  • Blogger has added support for openid if enabled but does not serve as a provider currently
  • Yahoo users can use their yahoo ids as OpenIDs starting January 31st, 2008.[4]

OpenID Foundation

The OpenID Foundation is a 501(c)3 non-profit incorporated in the United States. The OpenID Foundation was formed to help manage copyright, trademarks, marketing efforts and other activities related to the success of the OpenID community. The singular goal of the OpenID Foundation is to protect OpenID.


The OpenID Foundation's board of directors has seven members:[5]

  • Scott Kveton (MyStrands)
  • David Recordon (Six Apart)
  • Dick Hardt (Sxip)
  • Martin Atkins
  • Artur Bergman (Wikia)
  • Johannes Ernst (NetMesh)
  • Drummond Reed (Parity and OASIS XRI and XDI TCs)
  • Bill Washburn, Ph.D., of XDI.ORG, is the foundation's executive director.



RPX is a software as a service (SaaS) application that handles the user interface, authentication, and import of user profile and registration data for any web site. The API allows customization and integration.

OpenID Server

openid-server JOS (Java OpenID Server) is a multi-domain, multi-user OpenID Provider.

Legal issues

R-Objects Inc. filed for the OpenID trademark (serial 78899244) on 2006-06-02[6] which was published for opposition on 2007-01-09, claiming a first use date of 2005-05-17 and a first use in commerce date of 2006-04-18. Sxip Identity Corporation subsequently filed for the OpenID trademark (serial 77041930) on 2006-11-11[7] but abandoned it on 2006-11-23[8]. Randy "ydnar" Reddig claimed ownership of the OpenID logo on 2005-06-25 and announced plans to transfer it to Six Apart (or some

There is a pending USPTO patent application with PCT priority from Denmark of 2001-03-09 that covers the central aspects of OpenID.

Six Apart Ltd. are the registrant for the "official" domain, which was transferred from David I. Lehn on 2005-06-16.

The official site currently states:

Nobody should own this. Nobody's planning on making any money from this. The goal is to release every part of this under the most liberal licenses possible, so there's no money or licensing or registering required to play. It benefits the community as a whole if something like this exists, and we're all a part of the community.

Both Sun Microsystems and VeriSign have issued patent non-assertion covenants covering OpenID 1.1 specifications. These covenants [9] [10] state that neither company will assert any of their patents against OpenID implementations and will revoke their promises from anyone who threatens, or asserts, patents against OpenID implementors.


Some observers have suggested that OpenID has security weaknesses and may prove vulnerable to phishing attacks.[11] [12]

For example, a malicious relying party may forward the end user to a bogus identity provider authentication page asking that end user to input their credentials. On completion of this, the malicious party (who in this case also control the bogus authentication page) could then have access to the end user's account with the identity provider, and as such then use that end user’s OpenID to log into other services.

In an attempt to combat possible phishing attacks some OpenID providers mandate that the end user needs to be authenticated with them prior to an attempt to authenticate with the relying party. However this then relies on the end user knowing the policy of the identity provider, and regardless this issue remains a significant additional vector for man-in-the-middle phishing attacks.

Other criticisms are that the addition of a 3rd party (the identity provider) into the authentication process significantly adds complexity and therefore possibility of vulnerability into the system. Also this system shifts responsibility for "quality" of authentication to the end user (in their choice of identity provider), a shift that the end user and the relying party (for example their bank) need to understand.


  • RPX Now: (JanRain has been one of the leading voices in the developer community and have contributed code libraries and commercial out-of-the-box solutions for enabling OpenID on your site quickly and conveniently. They provide a commercial out-of-the-box solution for quickly and easily implementing the OpenID protocol, with hooks into major third party providers such as sxip,, MyOpenID, Facebook, MySpace, Google, Yahoo! and Windows Live / MSN (now with a "free" but limited version for instant use as well).)
  • OpenID Connect - Debugger tool:


Becoming a Provider


External links


  1. Current Firefox 3 Requirements on the Mozilla Wiki
  2. OpenID bounty sponsors:
  3. OSCON - The State of OpenID talk by Scott Kveton
  5. OpenID Foundation
  6. Application #78899244 on
  7. Application #77041930 on
  8. Notice of Abandonment for application #77041930 on
  9. Sun's OpenID Non-Assertion Patent Covenant
  10. VeriSign's OpenID Non-Assertion Patent Covenant
  11. : OpenID still open to abuse]
  12. Beginner's guide to OpenID phishing:
  13. Connect2id server: | SLIDES | DOWNLOAD
  14. Java cookbook for OpenID Connect public clients (using "Nimbus OAuth 2.0 SDK + OpenID Connect extension"):
  15. OpenID Connect - Java/Spring server:
  16. Shibboleth extension for OpenID Connect (in Java):
  17. Openid4Java - OpenID 2.0 Java Libraries: (leading legacy OpenID 2.0 SDK)
  18. Authenticate Java Spring Boot with OpenID Connect (OIDC) using Auth0:
  19. OneLogin OpenId Connect Spring Boot Sample:
  20. Full-Scratch Implementor of OAuth and OpenID Connect Talks About Findings:
  21. phpMyID: (previously the leading PHP implementation of OpenID)
  22. OpenID-LDAP:
  23. Authorization header missing in django rest_framework, is apache to blame?:
  24. What is the new phpMyID?:
  25. Installing Suhosin:

See also

Authentication | OAuth | JWT