Openid

In 2005, Brad Fitzpatrick , known as the creator of LiveJournal , who worked at Six Apart at that time, proposed to the Internet community the concept of a single account for various Internet resources ^[10] . He suggested storing his account on one server, and when registering on other Internet resources use this account. Initially, the protocol is called Yadis (an acronym for “Yet another distributed identity system”), it got the name OpenID-protocol after Six Apart registered the openid.net domain name for its project. Soon, OpenID support was implemented on LiveJournal, and this technology quickly attracted the attention of the Internet community ^[11] .

In 2006, the first OpenID specification was created - OpenID Authentication 1.1 ^[12] .

On December 5, 2007, Sun Microsystems , VeriSign and a number of companies involved in the development of OpenID released the OpenID 2.0 specification and officially announced that they would not make complaints if anyone uses OpenID technology unless the actions of the person using the technology are directed against the implementation of technology or the ownership of technology ^[13] .

The OpenID trademark was registered in the USA in March 2008 ^[14] .

On the site, for example, example.com , there is a login form with a single input field for the OpenID identifier. Often next to this field is the OpenID logo. In order to log in to this site using your identifier, for example, pupkin.openid-provider.org , registered with the OpenID provider openid-provider.org , you must enter your identifier in the login form offered on the site. After that, example.com redirects the user to the provider's site. The provider's site asks the user to confirm whether the user really wants to provide information about his account. If the user agrees, the provider's site redirects the user back to the site of the dependent party. In the case of reverse redirection, the provider will transmit user information to the dependent party ^[15] .

An OpenID provider, for example, is LiveJournal , so you can use the address of your diary in the LiveJournal as an OpenID identifier ^[16] .

OpenID Features

OpenID allows the user to use one account registered with the OpenID provider on many other sites. The user can choose what information to provide the site. Exchange of profile information or other information not described in the OpenID specification can be implemented over the OpenID protocol using additional types of services. For this, a protocol extension mechanism is officially supported by the OpenID protocol ^[17] .

There is the possibility of delegating OpenID. This means that the owner of a certain domain name can use it as a synonym (alias) for an existing OpenID identifier received from any OpenID provider. For this, it is necessary to add several meta tags to the page used as a delegate ^[18] .

Decentralization

The OpenID system is a decentralized system. This means that there is no central service or organization that permits the use of the system or registers Internet resources or OpenID providers requesting OpenID authentication. The end user can freely choose which OpenID provider to use, and save the Identifier in case of changing the OpenID provider ^[1] .

Technology Requirements

The standard does not require JavaScript or modern browsers , but the authentication scheme is well compatible with the AJAX approach. This means that the end user can authenticate on the site without leaving the current page. In this case, the communication of the Internet resource with the OpenID provider will take place in the background. OpenID authentication uses only standard HTTP (S) requests and responses, so the standard does not require the user to install additional software . OpenID does not require the use of cookies or any other session management mechanisms. Various extensions can simplify the use of OpenID, but are not required to use the standard ^[2] .

Terminology

• Identifier - HTTP or HTTPS URI (URL) or XRI (starting with OpenID 2.0) ^[2] . The protocol uses several types of identifiers.
• Relying Party Internet service is a web application that wants to verify the authenticity of a user ID.
• OpenID Provider (OpenID Provider) - An OpenID authentication server that confirms the authenticity of an end-user identifier to an Internet service.
• Provider Endpoint URL (OpenID Provider Endpoint URL) - A URL that accepts authentication requests using the OpenID protocol and can be obtained from the presented identifier.
• Provider Identifier (OP Identifier) ​​- identifier by which you can determine the OpenID of the provider.
• User-Supplied Identifier — An identifier presented by an end-user to an Internet service. The presented identifier may coincide with the OP identifier.
• Claimed Identifier - An identifier that the user claims ownership. Verification of this statement is the main goal of the OpenID protocol. The claimed identifier can be obtained from the presented by normalizing it ^[19] .

Mechanism of Operation

1. The end user initiates the authentication process on the Internet service. To do this, he enters the presented identifier in the login form presented on the site.
2. From the presented identifier, the Internet service determines the URL of the endpoint of the OpenID provider used by the end user. The presented identifier may contain only the Provider Identifier. In this case, the end user indicates his claimed identifier, interacting with the provider.
3. Optionally, the Internet service and the OpenID provider create a shared secret key for the message authentication code using the Diffie-Hellman protocol. Using the message authentication code, the Internet service authenticates the message from the provider without additional requests for authentication.
4. In checkid_setup mode checkid_setup Internet service redirects the user's browser to the provider's website for further authentication. In checkid_immediate mode, checkid_immediate communication with the provider is invisible to the user.
5. The provider checks whether the user is authorized on the server and whether he wants to authenticate with the Internet service. The OpenID specification does not describe the user authentication process on the provider side.
6. The provider redirects the user's browser back to the Internet service, passing the authentication result to the service.
7. The Internet service verifies the authenticity of information received from the provider, including the returned URL, user information, nonce and message signature. If a shared secret key was created in step 3, then the check is performed using it. If the key has not been created, the Internet service sends an additional request ( check_authentication ) to the provider for authentication. In the first case, the Internet service is called dumb ( dumb ), and in the second - the dependent side without memory ( stateless ).
8. In case of successful verification, the Internet service authenticates the user ^[15] .

The OpenID Foundation (OIDF) is a non-profit organization that was formed in June 2007 in order to manage copyrights, trademarks, marketing companies and other activities related to the OpenID community ^[20] .

The organization’s board of directors consists of 4 community members and 8 corporate members ^[21] :

In the United States in March 2008, the OpenID Foundation registered the OpenID trademark. Previously owned by NetMesh Inc. In Europe, on August 31, 2007, the OpenID trademark was registered by the OpenID Europe Foundation ^[14] .

OpenID 1.1

OpenID authentication provides a way to prove to the end user his identity on the site without entering his password, e-mail or other information that he does not want to enter on this resource. The OpenID 1.1 specification does not provide any mechanism for exchanging end-user profile information ^[18] .

OpenID 2.0

The main difference between OpenID 1.1 and OpenID 2.0 for the end user is the ability to use XRI as an identifier. OpenID 2.0, unlike OpenID 1.1, supports the HMAC-SHA256 algorithm , a 256-bit ( [RFC2104 ] digital signature, which makes authentication of OpenID messages safer. OpenID 2.0 has an extension mechanism that allows you to add additional information to authentication requests and responses ^{[ 22]} .

OpenID 2.0 is compatible with OpenID 1.1 ^[23] .

OpenID Connect

The third generation of OpenID technology, which is an authentication add-on over the OAuth 2.0 authorization protocol . OpenID Connect allows Internet resources to verify the identity of the user based on the authentication performed by the authorization server. For work, the RESTful API described in the specification is used. OpenID Connect also defines additional mechanisms for strong encryption and digital signature. The standard allows the use of additional features, such as session management and discovery of OpenID providers ^[8] .

While the integration of OAuth 1.0a with OpenID 2.0 requires an extension, in OpenID Connect the capabilities of OAuth 2.0 are already integrated with the protocol itself ^[24] .

Phishing attacks

Some researchers believe that the OpenID protocol is vulnerable to phishing attacks when instead of a provider, attackers send the end user to a site with a similar design. If the user does not notice the substitution, then he enters his authentication data (login, password). As a result, cybercriminals can present themselves to Internet resources as a given user and gain access to his information stored on these resources ^[25] .

Phishing attacks are also possible when a site that supports OpenID authentication is faked in order to obtain user information from the provider. Using the “covert redirect” vulnerability, attackers can create the illusion for the user that information is requested by this site ^[26] .

OpenID does not contain mechanisms to prevent phishing attacks. Responsibility for phishing attacks is shifted to OpenID providers ^[27] .

To protect against phishing, users can use additional software, such as Microsoft's Identity Selector ^[28] . There are also solutions that do not require the installation of additional software, for example, BeamAuth, which uses bookmarks in a browser for its work ^[29] .

Man in the Middle Attack with Unprotected Connection

If the TLS / SSL protocols are not used to protect the connection between the user and the OpenID provider, then a vulnerability arises at the last stage of authentication. To redirect the user from himself to the Internet service, the provider gives the user a special URL. The problem is that anyone who can get this URL (for example, by sniffing a twisted pair) can play it and gain access to the site as a user. Some providers use Nonce code to protect against this attack, which allows you to use this URL only once. The nons solution only works when the User first uses the URL. However, an attacker who is listening on the communication channel and is located between the user and the provider can obtain the URL and immediately terminate the user's TCP connection, and then perform an attack. Thus, one-time codes protect only from passive intruders, but cannot prevent the attacks of an active attacker. Using TLS / SSL in the authentication process eliminates this risk ^[30] .

ID reuse

The user can change the OpenID provider, thus freeing his identifier from the previous provider. A new user can take this identifier and use it on the same sites as the previous user. This will give the new user access to all the information associated with this identifier. This situation may occur by chance - it is not necessary that the new user be an attacker and want to gain access to the specified information ^[31] .

In the OpenID 2.0 specification, it is recommended to use fragments to solve the problem of reusing the identifier - a fragment unique to each user should be added to the identifier ^[19] .

Authentication Errors

In 2012, researchers published a paper describing two vulnerabilities in OpenID. Both vulnerabilities allow an attacker to gain access to the victim’s account ^[32] .

The first vulnerability exploits the OpenID Attribute Exchange. The problem is that some Internet services do not check the data transmitted through Attribute Exchange. If Attribute Exchange is used to transmit information about the user that is not sensitive to spoofing (for example, gender), then this vulnerability will not be possible to exploit. However, Attribute Exchange can also be used to transfer, for example, the user's email. The attacker attempts to authenticate on the site of the dependent party and adds the victim's email address to the provider. If the dependent party does not authenticate this information, the attacker will be identified as a victim. This way you can access any registered account. According to the researchers report, many popular sites, including Yahoo! Mail ^[33] .

The second vulnerability is related to an error on the provider's side and also allows access to the account on the site of the dependent party. The provider's response contains the openid.ext1.value.email field, which is processed by the dependent party as the user's email. However, the type of data that is added by the provider to this field can be controlled by an attacker - a request to the provider contains the type.email field with a link to the scheme that describes this field. An attacker can add a type.email link to a schema describing the username. If the attacker can register on the provider's website with the name, for example, alice@example.com, the provider will add this name to the openid.ext1.value.email field and the dependent party will consider that the account with this email belongs to the attacker. Implementations of Google and Paypal were recognized as vulnerable ^[33] .

OpenID published reports on both vulnerabilities, and updates were released that fix them ^{[34] [35]} .

• ResearcherID

• OpenID Authentication 2.0 Specification http://openid.net/ . OpenID Foundation. Date of treatment December 5, 2017.

• Microsoft and Google Both Ship OpenID . http://openid.net/ . OpenID Foundation. Date of treatment December 5, 2017.

• Technology Leaders Join OpenID Foundation http://www-03.ibm.com/ . IBM Date of treatment December 5, 2017.

• Steam Web API Documentation (Russian) . http://steamcommunity.com/ . Steam Date of treatment December 5, 2017.

• OpenID Attribute Exchange 1.0 http://openid.net/ . OpenID Foundation. Date of treatment December 5, 2017.

• OpenID 2009 Year in Review . http://openid.net/ . OpenID Foundation (December 15, 2009). Date of treatment December 5, 2017.

• OpenID Connect Core 1.0 http://openid.net/ . OpenID Foundation. Date of treatment December 5, 2017.

• Errata to OpenID Connect Specifications Approved . http://openid.net/ . OpenID Foundation. Date of treatment December 5, 2017.

• Brad Fitzpatrick. Distributed Identity: Yadis http://lj-dev.livejournal.com/ (16 May 2005). Date of treatment December 5, 2017.

• Brad Fitzpatrick. OpenID: an actually distributed identity system . http://www.danga.com/ (July 14, 2005). Date of treatment December 5, 2017. Archived September 24, 2005.

• OpenID Authentication 1.1 Specification http://openid.net/ . OpenID Foundation. Date of treatment December 5, 2017.

• OpenID.sun.com is open for business . https://blogs.oracle.com/ . Oracle (2007-6-6). Date of treatment December 5, 2017.

• USPTO Assignments on the Web - OpenID . http://assignments.uspto.gov/ . United States Patent and Trademark Office. Date of treatment December 5, 2017.

• What is OpenID? (eng.) . https://www.livejournal.com/ . Livejournal. Date of treatment June 27, 2005.

• What is OpenID? (eng.) . http://openid.net/ . OpenID Foundation. Date of treatment December 5, 2017.

• OpenID Foundation http://openid.net/ . OpenID Foundation. Date of treatment December 5, 2017.

• OpenID Foundation Leadership http://openid.net/ . OpenID Foundation. Date of treatment December 5, 2017.

• Welcome to OpenID Connect . http://openid.net/ . OpenID Foundation. Date of treatment December 5, 2017.

• Bart van Delft and Martijn Oostdijk. A security analysis of OpenID . - Springer. - S. 73-84 .

• Covert Redirect Vulnerability Related to OAuth 2.0 and OpenID (англ.) . http://www.tetraph.com/ . Teltraph. Дата обращения 5 декабря 2017.

• Ben Adida. Beamauth: Two-factor Web Authentication with a Bookmark . — ACM. — С. 48-57 . — ISBN 9781595937032 . — DOI : 10.1145/1315245.1315253 .

• Eugene Tsyrklevich. Single Sign-On for the Internet: A Security Story . — BlackHat USA.

• Rui Wang, Shuo Chen, XiaoFeng Wang. Signing Me onto Your Accounts through Facebook and Google: a Traffic-Guided Security Study of Commercially Deployed Single-Sign-On Web Services . — Microsoft Research.

• Attribute Exchange Security Alert (англ.) . http://openid.net/ . OpenID Foundation. Дата обращения 5 декабря 2017.

• Vulnerability report: Data confusion (англ.) . http://openid.net/ . OpenID Foundation. Дата обращения 5 декабря 2017.

• Announcing Facebook Connect - Facebook for Developers (англ.) . https://developers.facebook.com/ . Facebook Developers. Дата обращения 5 декабря 2017.