OpenID is an open standard that allows users to be authenticated by certain co-operating sites (known as Relying Parties or RP) using a third party service, eliminating the need for webmasters to provide their own ad hoc systems and allowing users to consolidate their digital identities.
Users may create accounts with their preferred OpenID identity providers, and then use those accounts as the basis for signing on to any website which accepts OpenID authentication.
The OpenID standard provides a framework for the communication that must take place between the identity provider and the OpenID acceptor (the "relying party").
An extension to the standard (the OpenID Attribute Exchange) facilitates the transfer of user attributes, such as name and gender, from the OpenID identity provider to the relying party (each relying party may request a different set of attributes, depending on its requirements).
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 (such as passwords) to the novel (such as smart cards or biometrics).
The term OpenID may also refer to an identifier as specified in the OpenID standard; these identifiers take the form of a unique URI, and are managed by some 'OpenID provider' that handles authentication.
OpenID authentication is now used and provided by several large websites. Providers include Google, Yahoo!, PayPal, BBC, AOL, LiveJournal, MySpace, IBM, Steam, Sherdog, Orange and VeriSign.
Technical Overview of OpenID
An end-user is the entity that wants to assert a particular identity. A relying party (RP) is a web site or application that wants to verify the end-user's identifier. Other terms for this party include "service provider" or the now obsolete "consumer". An identity provider, or OpenID provider (OP) is a service that specializes in registering OpenID URLs or XRIs. OpenID enables an end-user to communicate with a relying party. This communication is done through the exchange of an identifier or OpenID, which is the URL or XRI chosen by the end-user to name the end-user's identity. An Identity provider provides the OpenID authentication (and possibly other identity services). The exchange is enabled by a User-agent, which is the program (such as a browser) used by the end-user to communicate with the relying party and OpenID provider.
The end-user interacts with a relying party (such as a website) that provides an option to specify an OpenID for the purposes of authentication; an end-user typically has previously registered an OpenID (e.g. alice.openid.example.org) with an OpenID provider (e.g. openid.example.org).
The relying party typically transforms the OpenID into a canonical URL form (e.g. http://alice.openid.example.org/).
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 (e.g. http://openid.example.org/openid-auth.php). The relying party also discovers whether to use a delegated identity (see below).
With OpenID 2.0, the relying party discovers the OpenID provider URL by requesting the XRDS document (also called the Yadis 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 (optionally) 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 (check_authentication) 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 in to the relying party under the identity specified by the given OpenID (e.g. alice.openid.example.org). The relying party typically then stores the end-user's OpenID along with the end-user's other session information.
To obtain an OpenID-enabled URL that can be used to log into OpenID-enabled websites, a user needs to register an OpenID identifier with an identity provider. Identity providers offer the ability to register a URL (typically a third-level domain, e.g. username.example.com) 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 (such as a blog or home page) 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 (and some 1.1 implementations), 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 (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 end-user's OpenID identity ever being taken over by another party as can happen with a URL based on a reassignable DNS name.
Security Issues of OpenID
In March, 2012, a research paper reported two generic security issues in OpenID. Both issues allow an attacker to sign into a victim's relying party accounts. For the first issue, OpenID and Google (an Identity Provider of OpenID) both published security advisories to address it.
Google's advisory says "An attacker could forge an OpenID request that doesn't ask for the user's email address, and then insert an unsigned email address into the IDPs response. If the attacker relays this response to a website that doesn't notice that this attribute is unsigned, the website may be tricked into logging the attacker in to any local account.". The research paper claims that many popular websites have been confirmed vulnerable, including Yahoo! Mail, smartsheet.com, zoho.com, manymoon.com, diigo.com. The researchers have notified the affected parties, who have then fixed their vulnerable code. For the second issue, the paper called it "Data Type Confusion Logic Flaw", which also allows attacker to sign into victim's RP accounts. Google and PayPal are confirmed vulnerable. OpenID published a vulnerability report on the flaw. It says Google and PayPal have applied fixes, and suggest other OpenID vendors to check their implementations.
Some observers have suggested that OpenID has security weaknesses and may prove vulnerable to phishing attacks. 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 controls 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. This relies on the end-user knowing the policy of the identity provider. In December 2008, the OpenID Foundation approved version 1.0 of the Provider Authentication Policy Extension (PAPE), which "enables Relying Parties to request that OpenID Providers employ specified authentication policies when authenticating users and for OpenID Providers to inform the Relying Parties which policies were actually used."
Privacy / Trust Issue
Other security issues identified with OpenID involve lack of privacy and failure to address the trust problem. However, this problem is not unique to OpenID and is simply the state of the Internet as commonly used.
Authentication Hijacking in Unsecured Connection
Another important vulnerability is present in the last step in the authentication scheme when TLS / SSL are not used: the redirect-URL from the Identity Provider to the Relying Party. The problem with this redirect is the fact that anyone who can obtain this URL (e.g. by sniffing the wire) can replay it and get logged into the site as the victim user. Some of the Identity Providers use nonces (number used once) to allow a user to log into the site once and fail all the consecutive attempts.
The nonce solution works if the user is the first one to use the URL. However a fast attacker who is sniffing the wire can obtain the URL and immediately reset a user's TCP connection (as an attacker is sniffing the wire and knows the required TCP sequence numbers) and then execute the replay attack as described above. Thus nonces only protect against passive attackers but cannot prevent active attackers from executing the replay attack. Use of TLS/SSL in the authentication process eliminates this risk.
You May Also Like