on electronic participation, collective moderation, and voting systems Issue 6
2018-07-27
Unified User Management with LiquidFeedback
This article will present a technology based on the OAuth 2.0 standard to allow user identification on the internet: LiquidFeedback acts as an identity server, and, given a proper accreditation process for LiquidFeedback, other third-party software may use LiquidFeedback to verify identities when collecting quantified user input (single-sign-on with identity verification). This allows organizations or political administrations to build an extensible ecosystem of internet applications that are invulnerable to the sockpuppet problem where users create a number of (fake) internet identities to unfairly increase the impact of their postings or votes.
A necessary prerequisite to using this technology is a proper accreditation process of all participants who shall be eligible to take part in the deliberation process. This accreditation process is out of scope of this article and will differ according to the concrete application scenario.
For the most part of this article, we assume the reader is familiar with single-sign-on technologies as well as OAuth 2.0 as specified in RFC 6749.
This article is in large part based on the UWUM Work Report [UWUM]. LiquidFeedback's OAuth 2.0 server support as well as the UWUM Work Report have been contributed by FlexiGuided GmbH as part of the WeGovNow project which has received funding from the European Union's Horizon 2020 research and innovation programme under grant agreement No 693514.
Motivation
In the previous issue of The Liquid Democracy Journal, we mentioned that a central problem of internet participation systems had already been stated in 1995 by Rob Lanphier: without a verification of identities, you cannot ensure the basic democratic principle of “one person – one vote”. [Origins] Without that principle, even a single person may be able to manipulate the results of a vote. [Sockpuppet]
These findings cannot just be applied to electronic voting but are also valid for any other participation solution incorporating any form of opinion formation through counting of ratings (e.g. “likes”, “+1” or “thumbs up”). Consequently, it is not possible to quantify people's opinions on the internet without verifying their identity.
For the sake of inclusion, it has been proposed to allow people to participate anonymously with a reduced voting weight. Disregarding that this is already a violation of treating each participant equally, it can furthermore be proven mathematically that reducing the voting weight of anonymous participants to a fixed (but non-zero) value cannot solve the problem that creating a finite amount of so-called “sockpuppets” (fake identities) is sufficient to overrule the results of a vote. [Sockpuppet]
Lanphier was optimistic in regard to a solution of the identification problem on the internet, but until today (more than 20 years later), there is no standardized way to identify people. Many corporations are using their own solutions for identifying people, e.g. as customer or owner of a specific bank account, some governments have developed electronic identity systems for use with the internet, but there is no generally available solution which is practically feasible and intended to be used to authenticate and authorize participants for democratic participation processes using the internet.
When talking about solutions for verifying one's identity on the internet, we have to distinguish between:
- technologies (e.g. open source software, hardware appliances, standardized protocols, etc.) and
- their particular application (e.g. solutions created by particular organizations or states).
In the remainder of this article, we present a technology based on the OAuth 2.0 standard [RFC 6749] that has been developed as part of the EU-funded WeGovNow project and which has been incorporated into the LiquidFeedback software version 4.0, which is to be published soon. Ensuring that each person has at most one account in LiquidFeedback will automatically enable other (third-party) software to use LiquidFeedback to identify their users and thus avoid any problems with sockpuppets.
Existing alternatives
There are existing standards for single-sign-on procedures on the internet, and these also allow user identification. As we will explain in the following paragraphs, none of these solutions have matched our needs.
The most notable standard for single-sign-on (SSO) is the “OpenID Connect” standard. [OpenID] Unfortunately OpenID Connect is a rather complex standard and requires extra implementation work compared to the underlying OAuth 2.0 standard (which is much simpler to adopt).
Another alternative in mind was pure OAuth 2.0, but OAuth 2.0 has been created with a different application scenario and is out-of-the-box not suitable to provide a secure user identification and authentication. Lodderstedt, McGloin, and Hunt state in [RFC 6819] (“OAuth 2.0 Threat Model and Security Considerations”) that clients which wish to implement a user login should rather use “an appropriate protocol” such as OpenID or SAML instead of OAuth 2.0.
Nonetheless, using OAuth 2.0 with its “Authorization Code Flow” can still provide a lightweight way to create a secure authentication and identification service. Only a few (standard compliant) extensions are necessary to allow applications to query the user's identity. Similar approaches have been taken by platforms such as Facebook (“Facebook Login”) but are often tied to a particular platform and cannot be installed in a separate realm with a secure and/or application-specific accreditation process.
Despite problems with existing solutions, it was our intention to stick to existing standards where appropriate. Even with necessary extensions, we managed to make LiquidFeedback's identification service to be fully compliant with the OAuth 2.0 specification [RFC 6749].
From OAuth 2.0 to a single-sign-on solution
In order to use OAuth 2.0 as a single-sign-on solution, LiquidFeedback takes the role of the “authorization server” according to [RFC 6749] while other (third-party) components can take the role of “clients” and “resource servers”.
However, OAuth 2.0 provides different modes of operation (e.g. the “Authorization Code Flow” and the “Implicit Flow”) and is by itself not sufficient for user authentication. Both the Authorization Code Flow and the Implicit Flow could be extended to provide user authentication and thus allow to implement a single-sign-on (SSO) system where third-party services on the internet can identify users. Because the Implicit Flow would require additional security mechanisms to be implemented at client side (where bad implementations result in security vulnerabilities), [RFC 6749, subsection 10.16] LiquidFeedback extends the Authorization Code Flow for user identification purposes.
In short, the Access Token Response of the OAuth 2.0 Authorization Code Flow gets extended by simply returning an additional field “member_id” which identifies the signed-in user. For details, refer to [UWUM].
(Dynamic) Client registration
The OAuth 2.0 standard [RFC 6749] requires a procedure called “client registration” without defining how this procedure is to be carried out. In the following, we explain about the problems that can come along with such a client registration and how we deal with them.
Client registration means that any component wishing to use the authorization server needs to be known to the authorization server beforehand. There are a couple of well-founded security reasons why this client registration is necessary. [UWUM, subsection 2.4.2] Nonetheless, this client registration is one of the biggest drawbacks of the OAuth 2.0 protocol: either clients can register without manual verification and approval by the operator of the authorization server, in which case the security concerns are often not fully addressed, or a manual verification is conducted in which case additional workload is imposed on the operator of the authorization server and/or certain clients might be excluded from using the authorization server. Furthermore, when using OAuth 2.0 for API authentication (which is its original field of application), manual client registration prohibits the creation of generic clients (e.g. alternative user interfaces) which may directly connect to any instance of a particular software installation (e.g. connect to LiquidFeedback instances in different municipalities or organizations).
The OAuth 2.0 specification [RFC 6749] does not care about these problems at all and simply states that client registration is out of scope of the standard and would “typically involve end-user interaction with an HTML registration form”:
This form of client registration, however, is only suitable for a service-centered approach where a software provides only a single service (e.g. Facebook, Google, Twitter, etc). When considering an open source ecosystem, we expect more than one installation of a particular technological solution. It is therefore not sufficient to register a client at a single service provider if this client shall be usable for any authorization server using the same (open source) software.
One possible solution would be the creation of a central (i.e. world-wide) client registry. Such a central client registry, however, could be a single point of failure and would empower a central authority (e.g. the Public Software Group) to control usage of the protocol (e.g. it would be possible to block certain clients). We consider this approach contrary to the concepts of open source and open data.
Therefore, we implemented a dynamic client registration protocol that keeps implementational complexity at a minimum while providing good security properties. Dynamic client registration is described in subsection 2.4.2 of [UWUM].
Further tweaks
LiquidFeedback's OAuth 2.0 server implementation can also be used for all other purposes that OAuth 2.0 may be used for. Further improvements have been made to extend the basic OAuth 2.0 workflow. For example, subsection 10.4 of [RFC 6749] suggests refresh token rotation to provide better security properties but does not specify how old refresh tokens are invalidated. Always revoking the old refresh token after transmission of a new refresh token can have a bad effect on system stability, considering that transmissions might not be processed properly by the receiver. Furthermore, multiple backends of a client could simultaneously access the OAuth 2.0 token endpoint. Such legit accesses by two legit backends of the same client would need to be distinguished from accesses by a legit client and a malicious third party who obtained a copy of a refresh token. Subsection 2.15 of [UWUM] explains the mechnanisms employed by LiquidFeedback to mitigate the risk of refresh token abuse while solving the problems of race conditions during refresh token rotation.
Another improvement, for example, is to allow downgrading access token scopes to allow meta-API providers as explained in subsection 2.14 of [UWUM].
Summary
Arguably, the biggest problem with the OAuth 2.0 standard is that it only provides a framework for authorization while keeping cruicial details undefined such as client registration. Those details, however, must be well-defined in order to provide a secure yet flexible authentication service.
Integrating an OAuth 2.0 server with appropriate extensions into LiquidFeedback automatically empowers all organizations or political administrations which use LiquidFeedback to provide identity services to third-party applications, even those applications unknown to the organization at time of deployment.
This project has received funding from the European Union's Horizon 2020 research and innovation programme under grant agreement No 693514.