OpenID is the standard open decentralized authentication protocol.
Promoted by the nonprofit OpenID Foundation, allowing users to be authenticated by collaboration sites (known as Relying on Parties or RPs) using third party services, eliminating the need for webmasters to provide their own ad hoc login system, and allowing users to log in to multiple websites not related without having a separate identity and password for each.
A user creates an account by selecting an OpenID identity provider, and then using that account to sign in to any website that receives OpenID authentication. Some large organizations publish or accept OpenID on their websites according to the OpenID Foundation:
The OpenID standard provides a framework for communication that must be done between identity providers and OpenID acceptors ("relying parties"). The default extension (OpenID Attribute Exchange) facilitates the redirection of user attributes, such as names and genders, from OpenID identity providers to dependent parties (each leaning party may request a different set of attributes, depending on the conditions).
The OpenID protocol does not rely on central authority to authenticate the user's identity. In addition, both OpenID services and standards can not mandate specific tools for authenticating users, enabling approaches ranging from common (such as passwords) to novels (such as smart cards or biometrics).
The term OpenID can also refer to the identifier as specified in the OpenID standard; This identifier takes the unique form of Uniform Resource Identifier (URI), and is managed by some 'OpenID providers' that handle authentication.
The current OpenID Connect 1.0 version, completed and published in February 2014, and updated with corrections in November 2014.
Video OpenID
Adoption
As of March 2016, there are over 1 billion OpenID enabled accounts on the Internet (see below) and about 1,100,934 sites have integrated OpenID consumer support: AOL, Blogger, Flickr, France Telecom, Google, Amazon.com, Canonical (name provider Ubuntu One), LiveJournal, Microsoft (Microsoft account provider name), Mixi, Myspace, Novell, Orange, Sears, Sun, Telecom Italia, Universal Music Group, VeriSign, WordPress, Yahoo !, BBC, IBM, PayPal, and Steam, although some of these organizations also have their own authentication management.
Many if not all larger organizations require users to provide authentication in the form of an existing email account or mobile phone number to sign up for an account (which can then be used as an OpenID identity). There are several smaller entities that accept registration without the necessary additional identity details.
Facebook did use OpenID in the past, but moved to Facebook Connect.
Maps OpenID
Technical description
An end user is the entity that wants to assert a certain identity. A relying (RP) is a website or app that wants to verify an end user identifier. Other terms for this party include the now-obsolete "service" or "consumer" providers. Identity providers, or OpenID (OP) providers are services that specialize in registering OpenID or XRI URLs. OpenID enables end users to communicate with those who rely on it. This communication is done through an exchange of identifiers or OpenID , which is the URL or XRI selected by the end user to name the end user. The identity provider provides OpenID authentication (and possibly other identity services). The exchange is enabled by user-agent , which is a program (such as a browser) used by end users to communicate with relying parties and OpenID providers.
Sign in
End users interact with a reliant party (such as a website) that provides the option to assign OpenID for authentication purposes; end-users usually have previously registered OpenID (eg alice.openid.example.org ) with OpenID provider (eg openid.example.org ).
Relying parties typically turn OpenID into a canonical URL form (eg http://alice.openid.example.org/).
- With OpenID 1.0, the lean party then requests HTML resources identified by the URL and reads the HTML link tag to find the URL of the OpenID provider (eg
http://openid.example.org/openid -auth.php). The dependent party also finds out whether to use delegated identity (see below). - With OpenID 2.0, relying parties find OpenID provider URLs by requesting XRDS documents (also called Yadis documents ) with content type
apps/xrds xml; this document may be available in the target URL and is always available for the target XRI.
There are two modes in which the relying parties can communicate with the OpenID provider:
-
checkid_immediate, where the dependent party requests that the OpenID provider not interact with the end user. All communications are communicated through an end user user agent without explicitly notifying the end user. -
checkid_setup, where the end user communicates with the OpenID provider through the same user agent that is used to access a dependent party.
The checkid_immediate mode can return to checkid_setup mode if the operation can not be automated.
First, the relying party and OpenID provider (optionally) create a shared secret, referenced by the partner's handle , which is then stored by the relying party. If using the checkid_setup mode, the reliant will redirect the end-user's agent to the OpenID provider so that the end-user can authenticate directly with the OpenID provider.
The authentication method may vary, but typically, OpenID providers request an end user for a password or cryptographic token, and then ask whether the end user trusts the reliant party to receive the required identity details.
If an end user rejects an OpenID provider's request to trust a relying party, the user agent is redirected back to a relying party with a message indicating that the authentication is rejected; the relying party in turn refuses to authenticate the end user.
If an end user accepts an OpenID provider request to trust a relying party, the user agent is redirected back to a party that relies on it along with end user credentials. The party that relies on it should then confirm that the credentials actually originate from the OpenID provider. If the relying party and the previous OpenID provider have created a shared secret, then the leaner may validate the identity of the OpenID provider by comparing copies of the secrets shared with those received with the end user credentials; Such leaning parties are called stateful because it keeps a shared secret between sessions. Conversely, a rigid no-country or stupid party should create one additional background request ( check_authentication ) to ensure that the data is indeed from an OpenID provider.
After OpenID is verified, authentication is considered successful and the end user is considered logged in to the party that relies on the identity specified by the given OpenID (eg alice.openid.example.org ). Relying parties usually then store OpenID end users along with other end user session information.
Identifier
To obtain URLs that enable OpenID that can be used to log in to websites that support OpenID, users register an OpenID identifier with the identity provider. The identity provider offers the ability to register URLs (typically third-level domains, such as username.example.com) that will automatically be configured with the OpenID authentication service.
Once they register OpenID, users can also use URLs that are under their own control (such as blogs or home pages) as aliases or "delegated identities". They simply enter the appropriate OpenID tag in HTML or serve the 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: URL and XRI.
XRI is a new form of Internet identifier designed specifically for cross-domain digital identity. For example, XRI comes in two forms - i-names and i-numbers - which are usually listed simultaneously as synonyms. My names can be reassigned (like domain names), while i-numbers are never moved. When the -XRI name is used as an OpenID identifier, it is immediately resolved to an identical i-number (CanonicalID element of the XRDS document). This I-number is an OpenID identifier that is stored by a relying party. In this way, both the user and the relying party are protected from an end user's OpenID identity that has been taken over by another party as may occur with a URL based on a re-assignable DNS name.
OpenID Foundation
The OpenID Foundation (OIDF) promotes and enhances OpenID community and technology. OIDF is a nonprofit international standards development organization of individual developers, government agencies and companies that want to promote and protect OpenID. The OpenID Foundation was formed in June 2007 and serves as a public trust organization representing open developer, vendor, and user communities. OIDF assists the community by providing the necessary infrastructure and helps in promoting and supporting OpenID adoption. This includes managing intellectual property and trademarks and promoting virus growth and global participation in OpenID.
People
The board of directors of the OpenID Foundation has four community members and eight members of the company:
Chapter
OIDF is a global organization to promote digital identity and to encourage further adoption of OpenID, OIDF has encouraged the formation of member chapters. The member chapters are officially part of the Foundation and work in their own constituencies to support the development and adoption of OpenID as a framework for user-centered identity on the internet.
Intellectual Property and Contribution Agreement
OIDF ensures that the OpenID specification is freely applicable so that OIDF requires all contributors to sign a contribution agreement. This Agreement grants the Foundation a copyright license to publish collective specifications and includes patent non-affirmation agreements. The non-statement agreement states that the contributors will not sue someone to apply the OpenID specification.
Legal issues
OpenID trademarks in the United States were assigned to the OpenID Foundation in March 2008. It has been registered by NetMesh Inc. before OpenID Foundation operates. In Europe, on August 31, 2007, the OpenID trademark is registered with the OpenID Europe Foundation.
The OpenID logo was designed by Randy "ydnar" Reddig, who in 2005 has declared a plan to transfer rights to the OpenID organization.
Since the original OpenID announcement, the official website has stated:
No one should have this. No one plans to make money from this. The goal is to release any part of this under the most liberal license possible, so no money or license or registration is required to play. It benefits the community as a whole if something like this exists, and we are all part of the community.
Sun Microsystems, VeriSign and a number of small companies involved in OpenID have issued a non-affirmative patent agreement that includes OpenID 1.1 specifications. The Agreement states that companies will not affirm their patents against the adoption of OpenID and will revoke their promises from anyone who threatens, or affirms, patents against OpenID implementers.
Security
Authentication bug
In March 2012, a research paper reported two common security issues in OpenID. Both problems allow the attacker to log in to the victim's victim-relay account. For the first edition, OpenID and Google (OpenID Identity Provider) publish a security guide to address them. A Google adviser says "An attacker can forge an OpenID request that does not ask for a user's email address, and then enter an unsigned email address into IDP responses.If the attacker submits this response to a website that does not notice that this is an unsigned Attribute, the website can be tricked by logging an attacker to a local account. "The research paper claims that many popular websites have been confirmed vulnerable, including Yahoo! Mail, smartsheet.com, Zoho, manymoon.com, diigo.com. Researchers have informed the affected parties, which then improved their vulnerable code.
For the second edition, the newspaper calls it "Data Type Confusion Logic Flaw", which also allows an attacker to log in to the victim's RP account. Google and PayPal were initially confirmed vulnerable. OpenID publishes vulnerability reports on defects. The report says Google and PayPal have implemented improvements, and recommend other OpenID vendors to check their implementation.
Phishing
Some observers have suggested that OpenID has security flaws and may prove vulnerable to phishing attacks. For example, malicious broadcasters may forward end users to a fake identity provider authentication page that asks the end user to enter their credentials. Upon completion of this, the malicious party (which in this case also controls the fake authentication page) can then have access to the end user account with the identity provider, and then use the end user's OpenID to log in to another service.
In an effort to combat possible phishing attacks, some OpenID providers mandate that end users should be authenticated with them before attempting to authenticate with a lean party. This depends on the end user who knows the identity provider policy. In December 2008, OpenID Foundation approved version 1.0 of the Extension Authentication Policy Provider (PAPE), which "allows the Reliable Person to request OpenID Providers to use certain authentication policies when authenticating users and for OpenID Providers to inform the Relies Party on which the policy is actually used."
Privacy/Trust Problem
Other security issues identified with OpenID involve a lack of privacy and a failure to address confidence issues. However, this issue is not unique to OpenID and only the state of the Internet as it is commonly used.
The Identity Provider, however, gets logs from your OpenID login; they know when you go to what website, making cross-site tracking much easier. A compromised OpenID account also tends to be a more serious privacy violation than a compromised account on one site.
Piracy Authentication in Unsafe Connection
Another important vulnerability is present in the last step in the authentication scheme when TLS/SSL is not used: redirect-URL from Identity Provider to Relying Party. The problem with this redirect is the fact that anyone who can get this URL (for example by sniffing a cable) can play back and log on to the site as a victim user. Some Identity Providers use nonces (a one-time-used number) to allow users to login to a site once and fail all successive attempts. The nonce solution works if the user is the first to use the URL. But a fast attacker who sniffs the wire can get the URL and immediately reset the user's TCP connection (as the attacker sniffs the cable and knows the required TCP sequence number) and then runs the replay attack as described above. Thus, the nonces only protect against the passive attacker but can not prevent the active attacker from executing the replay attack. Use of TLS/SSL in the authentication process removes this risk.
This can be restated as:
  IF (Both RP1 and RP2 have Bob as client)//Unusual case   AND (Bob uses the same IDP with RP1 and RP2)//Common case   AND (RP1 does not use VPN/SSL/TLS to secure their connection with clients)//Preventable!   THEN     RP2 can get enough credentials to emulate Bob with RP1   LAST IF
Covert Redirect
On May 1, 2014, a bug named "Covert Redirect associated with OAuth 2.0 and OpenID" was disclosed. It was discovered by doctoral student of mathematics Wang Jing in School of Physics and Mathematical Sciences, Nanyang Technological University, Singapore.
The OpenID announcement is: "'Covert Redirect', published in May, 2014, is an example of an attacker using open redirectors - a well-known threat, by well-known prevention methods.The OpenID Connect protocol mandates stricter actions that prevent open redirectors from preventing this vulnerability."
"The general consensus, so far, is that Covert Persuasion is not that bad, but it is still a threat, understanding what makes it dangerous requires a basic understanding of Open Transfer, and how it can be exploited."
Patch is not available soon. Ori Eisen, founder, chairman and chief innovation officer at 41st Parameter told Sue Marquette Poremba, "In a distributed system, we calculate the good nature of the participants to do the right thing.In cases like OAuth and OpenID, so it's unreasonable to expect every website to be patched in the near future ".
History
The original OpenID authentication protocol was developed in May 2005 by Brad Fitzpatrick, creator of the popular LiveJournal community site, while working at Six Apart. Originally referred to as Yadis (an abbreviation for "Yet another distributed identity system"), it was named OpenID after the openid.net domain name was given to Six Apart to be used for the project. OpenID support was soon implemented in LiveJournal and fellow LiveJournal DeadJournal engine community for blog post comments and quickly gained attention in the digital identity community. The web developer JanRain is an early supporter of OpenID, providing OpenID software libraries and expanding its business around OpenID-based services.
At the end of June, discussions began between OpenID users and developers of the NetMesh enterprise software company, leading to a collaboration on interoperability between Light-Weight Identity (LID) protocols similar to OpenID and NetMesh. The immediate outcome of the collaboration is the Yadis discovery protocol, adopting the name originally used for OpenID. The new Yadis was announced on October 24, 2005. After a discussion at the Internet Identity Workshop 2005 a few days later, the XRI/i developer joined the Yadis project, contributing the Extensible Resource Descriptor Sequence (XRDS) format for utilization in the protocol.
In December, developers at Sxip Identity started discussions with the OpenID/Yadis community after announcing changes in the development of version 2.0 of the Simple Extensible Identity Protocol (SXIP) to URL-based identities such as LID and OpenID. In March 2006, JanRain developed a Simple Registration (SREG) extension for OpenID that allowed primitive profile exchanges and in April submitted a proposal to formalize the extension to OpenID. In the same month, the work also started by combining full XRI support into OpenID. Around early May, main OpenID developer David Recordon left Six Apart, joining VeriSign to focus more on identity and digital guides for the OpenID specification. In early June, the main difference between the SXIP 2.0 and OpenID projects was solved with an agreement to support multiple personalities within OpenID by submitting an identity provider URL rather than a full identity URL. With this, as well as the addition of extension and XRI support in progress, OpenID evolves into a full digital identity framework, with Recordon proclaiming "We view OpenID as an umbrella for the framework that includes layers for identifier, discovery, authentication and messaging services layers that sit above and across it has been dubbed 'OpenID 2.0'. "In late July, Sxip began incorporating the Digital Identity Exchange (DIX) protocol into OpenID, sending an initial draft of the Extension OpenID Exchange (AX) Attribute in August. The end of 2006, a ZDNet opinion piece made the case for OpenID for users, website operators and businessmen.
On January 31, 2007, Symantec announced support for OpenID in its Identity Initiative products and services. A week later, on February 6, Microsoft made an announcement with JanRain, Sxip and VeriSign to collaborate on the interoperability between OpenID and Microsoft Windows CardSpace digital identity platform, with a particular focus on developing an anti-phishing authentication solution for OpenID. As part of the collaboration, Microsoft promises to support OpenID in its future identity server products and JanRain, Sxip, and VeriSign promise to add support for Microsoft's Information Card profiles for their future identity solutions. In mid-February, AOL announced that the Experimental OpenID provider service works for all AOL and AOL Instant Messenger (AIM) accounts.
In May, Sun Microsystems started working with the OpenID community, announced OpenID programs, and entered a non-statement agreement with the OpenID community, promising not to affirm one of its patents against OpenID implementation. In June, OpenID's leadership established the OpenID Foundation, an Oregon-based public assistance company to manage OpenID brands and properties. In the same month, an independent OpenID Europe Foundation was formed in Belgium by Snorri Giorgetti. In early December, a non-statement agreement was compiled by major contributors to the protocol and specifications of OpenID Authentication 2.0 and OpenID Attribute Exchange 1.0 ratified on 5 December.
In mid January 2008, Yahoo! announced initial OpenID 2.0 support, both as a provider and as a reliant party, releasing provider services by the end of the month. In early February, Google, IBM, Microsoft, VeriSign, and Yahoo! joined the OpenID Foundation as a board member of the company. Around early May, SourceForge, Inc. introducing OpenID providers and relying on party support to open the open source software development website SourceForge.net. At the end of July, popular social networking service MySpace announced support for OpenID as a provider. In late October, Google launched support as an OpenID provider and Microsoft announced that Windows Live ID would support OpenID. In November, JanRain announced a free hosted service, RPX Basic, which allows the website to start receiving OpenID for registration and login without having to install, integrate and configure OpenID OpenID libraries.
In January 2009, PayPal joined the OpenID Foundation as a member of the company, followed by Facebook in February. The OpenID Foundation formed an executive committee and appointed Don Thibeau as executive director. In March, MySpace launched the previously announced OpenID provider service, allowing all MySpace users to use their MySpace URL as OpenID. In May, Facebook launched the functionality of those who rely on them, allowing users to use OpenID accounts that are enabled with automatic login (eg Google) to log in to Facebook.
In September 2013, Janrain announced that MyOpenID.com will close on February 1, 2014; the pie chart shows Facebook and Google dominating the social entrance space since Q2 2013. Facebook has since left OpenID; it is no longer a sponsor, represented on the board, or permits OpenID login.
In May 2016, Symantec announced that it will stop their personal identity port ID service pip.verisignlabs.com.
In March, 2018, StackOverflow announced an end to OpenID support, citing OpenID's very low popularity compared to OAuth.
OpenID vs. pseudo-authentication using OAuth
OpenID is a way to use a set of user credentials to access multiple sites, while OAuth facilitates the authorization of one site to access and use information associated with a user account on another site. Although OAuth is not an authentication protocol, OAuth can be used as part of a single protocol. The following figure highlights the difference between using OpenID vs. OAuth for authentication. Note that with OpenID, the process begins with an application that asks the user for their identity (usually UID OpenID), whereas in the case of OAuth, the app directly requests limited access OAuth Token (valet key) to access the API (enter home) on behalf of the user. If a user can grant that access, the app can take a unique identifier to assign a profile (identity) using the API.
OpenID Connect
Published in February 2014 by OpenID Foundation, third generation OpenID technology, OpenID Connect , is an authentication layer that is above the OAuth 2.0 authorization framework. This enables the computing client to verify the identity of the end user based on the authentication performed by the authorization server, as well as to obtain basic profile information about the end user in an operable and REST-like manner. In technical terms, OpenID Connect specifies a RESTful HTTP API, using JSON as the data format. OpenID Connect allows organizations, including web, mobile and JavaScript clients, to request and receive information about authenticated sessions and end users. The OpenID Connect specification can be expanded, supporting optional features such as identity data encryption, OpenID provider discovery, and session management.
See also
References
External links
- Official website
- OpenID in Curlie (based on DMOZ)
Source of the article : Wikipedia
0 Comments