A Comparative Survey of Centralised and Decentralised Identity Management Systems: Analysing Scalability, Security, and Feasibility

Abstract

Traditional identity management (IdM) solutions based on centralised protocols, such as Lightweight Directory Access Protocol (LDAP) and Security Assertion Markup Language (SAML), are where a central authority manages all the processes. This risks a single point of failure and other vulnerabilities. In response, decentralised techniques like blockchain and decentralised identities (DIDs) are being explored. This review paper performs a comparison of popular decentralised identity management (DIM) protocols, such as self-sovereign identity (SSI), against traditional centralised approaches such as LDAP and SAML. These decentralised identity management systems are being developed, keeping users’ identity data as its highest priority. Additionally, this method eliminates the need for a central authority to manage and secure the system. To further explore the potential of decentralised identity management, this study delves into popular blockchain-based decentralised identity management systems such as uPort, Sovrin, EverID, Blockstack, ShoCard, and Hyperledger Indy. We analyse their underlying principles and compare them with the well-established centralised identity management solutions, focusing on key aspects such as scalability, security, and feasibility. However, despite their benefits and several worthy developments in this field, decentralised approaches are still not widely used. Through this study, we investigate both centralised and decentralised methods and review their strengths and weaknesses. By reviewing multiple research papers, this survey aims to provide an understanding and aid in selecting the most suitable identity management system for different use cases.

1. Introduction

In an era where cybercrime is at its peak, digital identity has become critical, especially as digital assets multiply and individuals become more connected. Digital assets are valuable and include sensitive personal information. These assets include digital currency (bitcoin), online profiles, and other types of personal data, all of which have significant value [1]. Digital identities enable people to prove their identity in the online world. This allows them to access and manage their resources in a safe manner [2]. Making sure people have the right to access their own digital assets is important to stop fraud and prevent others from getting hold of others’ personal data without permission [3]. Digital identity management helps keep our data safe while giving secure access to online services like social media, banking, and shopping. As we utilize digital networks more and more, protecting our digital identities becomes increasingly crucial. By securing our personal information, digital IDs provide us the confidence to use the internet safely and conveniently [2].

Back in the early 1990s (see Figure 1), digital identity systems were very simple. They relied only on usernames and passwords. People had to sign up with various service providers, which required them to manage multiple identities. This quickly grew inefficient, and many people began using the same passwords on many sites, making security breaches more likely [4]. Personal data were vulnerable to hacking and unauthorised access due to the inadequate authentication techniques used. As the issues increased, more complicated methods of managing digital identities emerged. Digital identity security made major progress with the advent of single sign-on (SSO), biometrics-based authentication, and multi-factor authentication (MFA) [5]. These innovations addressed some of the issues in older authentication methods and made authentication both more secure and convenient.

Despite these advances in digital identity management, traditional methods of storing and processing identities have generally remained centralised, where servers located and managed from a central location handle the storage and processing of user identities. We often use services like Google, Microsoft, Facebook, and Instagram, where identity verification is required, and these organizations, either directly or through providers like ID.me, Okta, or Auth0, manage and store identity data centrally. However, centralised systems come with inherent vulnerabilities. Since centralised systems have a single point of failure due to a single point of control, they are susceptible to various kinds of attacks, technical malfunctions, and data breaches [2]. Attackers may obtain sensitive identifiable information from a compromised central server, potentially leading to identity theft and illegal access to private and financial data.

Furthermore, massive databases and significant computing power are commonly required for centralised identity systems to store and manage user data. This can lead to scalability issues. Also, as users’ personal data are stored in centralised servers, it may raise concerns related to security and privacy of the data [6].

Concerns regarding the security and privacy of users’ identities were substantial, and several attacks on centralised systems were observed, which encouraged the exploration of decentralised identity management. Blockchain, being decentralised and one of the safest ways to process transactions anonymously, distributes control across a network of nodes. This decentralised method reduces the risk of a single point of failure and has proven to be more secure and resilient against cyberattacks and system failures [7]. The control and authentication process is distributed across a network of autonomous nodes (participants), ensuring that no single party controls the system. Additionally, because blockchain is immutable—meaning that data, once written, cannot be altered—it adds another layer of security against fraud, data tampering, and illegal access [2,6].

This approach is more user-centric, giving users full control over what data they want to share and how much. Platforms such as uPort, Hyperledger Indy, and EverID have made significant progress in this area and will be discussed in detail in the upcoming sections of this paper. Companies like EarthID and Yoti (using similar decentralised methods for identity management) have gained popularity in the UK for consumer-facing and practical identity verification solutions, which are used daily across sectors such as retail, social media, finance, and the government. Their use cases include age verification, KYC, and event check-ins. Yoti, for example, is used by several large organizations, including big banks for biometric identity verification, national postal services for digital identity verification, popular social media platforms, and some nightclubs where age verification (18+) is required. Users can verify their identity or age (e.g., proving they are 18+) without sharing unnecessary details, such as their exact date of birth. Despite these advantages, decentralised authentication systems have struggled to gain widespread acceptance, particularly in real-time organizational settings. Implementing decentralised identity management systems necessitates significant infrastructure upgrades and financial investments. In addition to establishing the decentralised infrastructure, organizations must also provide staff with the necessary training to properly manage and operate these systems. This can be a costly and time-consuming process, especially for companies that are already heavily invested in centralised identity management systems [8].

Moreover, many existing applications and systems are designed with centralised architectures in mind, making the integration of decentralised authentication mechanisms a complex and challenging task. Careful planning and execution are required to ensure a smooth transition from centralised to decentralised systems [9]. While decentralised identity management systems offer superior security and resilience, they are not without risks. For example, blockchain networks are vulnerable to 51% attacks, where a group of malicious nodes gains control over the majority of the network’s computational power, allowing them to manipulate transactions and potentially compromise the system’s integrity [10].

As a result, even decentralised systems require continuous monitoring and updates to protect against emerging threats. This underscores the importance of having a robust and adaptable identity management infrastructure, regardless of whether the system is centralised or decentralised.

This comparative study of centralised and decentralised authentication systems reveals distinct advantages and challenges with each approach. Centralised systems, which have been used for decades, are easier to implement and have evolved to address many security concerns. However, they remain vulnerable to scalability issues, privacy risks, and single points of failure. In contrast, decentralised systems offer enhanced security, scalability, and user control but are more complex and costly to implement [8,11].

1.1. Purpose of the Study

The paper examines recent advancements and case studies from various authors and seeks to provide a detailed understanding of the present state of authentication and the prospects of a new decentralised authentication system. We will compare aspects such as security, interoperability, adaptability, and others, to assess whether decentralised authentication represents a substantial shift in digital security or if it remains largely theoretical hype.

1.2. Structure of the Review Article

The comprehensive study will begin by discussing various centralised authentication methods, such as LDAP, SAML, and OAuth, exploring how these systems work, their implementation processes, and their effectiveness in different contexts. Furthermore, we will look at decentralised authentication approaches and some of their recent models such as uPort, Sovrin, ShoCard, etc., highlighting their architecture, advantages, and challenges. By examining recent advancements, case studies, and current trends in identity management, we seek to assess the suitability of each approach for different use cases, ultimately offering insights into the future of digital identity and authentication.

2. Methodology and Scope of the Review

2.1. Scope of the Study

This paper systematically compares decentralised identity management (IdM) systems with traditional centralised IdM solutions. The focus is on evaluating these systems based on scalability, security, feasibility, and user control.

The scope includes the following:

• Decentralised IdM Systems: Systems like Hyperledger Indy, Sovrin, uPort, and Blockstack that use blockchain or distributed ledger technology and align with self-sovereign identity principles.
• Centralised IdM Systems: Traditional systems and protocols, including LDAP, SAML, OAuth, and RADIUS, which have been widely adopted over decades.
• Included Theoretical Studies: Both theoretical and practical studies were included, provided they offer meaningful insights into scalability, security, feasibility, or user control.
• Excluded Topics: Papers unrelated to identity management, such as those focusing solely on policy, non-digital identity frameworks, or unrelated blockchain use cases, were excluded.

2.2. Research Question

The guiding research question for this review is “How do decentralised IdM protocols compare to traditional centralised IdM solutions in terms of scalability, security, feasibility, and user control?”

2.3. How We Found the Research Papers

The search for relevant studies was carried out systematically, based on a defined strategy to ensure thoroughness and relevance. This involved the following steps:

2.3.1. Step 1: Define Key Concepts

The following key concepts were identified to guide the search:

• Decentralised Identity Management: Terms such as ‘self-sovereign identity’, ‘DID’, ‘decentralized IdM’, and ‘distributed identity management’.
• Centralised Identity Management: Terms such as ‘SAML’, ‘OAuth’, ‘LDAP’, and ‘Active Directory’.
• Blockchain: Terms such as ‘blockchain’, ‘Hyperledger Indy’, ‘Sovrin’, ‘uPort’, and ‘distributed ledger technology (DLT)’.
• Evaluation Criteria: Terms such as ‘scalability’, ‘security’, ‘feasibility’, ‘privacy’, ‘authentication’, and ‘implementation challenges’.

2.3.2. Step 2: Construct Search Strings

Boolean operators (AND, OR) were used to combine keywords effectively, for example:

(“decentralized identity management” OR “self-sovereign identity” OR “DID”) AND (“blockchain” OR “Hyperledger Indy” OR “Sovrin”) AND (“scalability” OR “security” OR “feasibility”)

This strategy allowed for broad coverage of relevant studies in both decentralized and centralized IdM systems.

2.3.3. Step 3: Search Databases

The search was carried out in the following academic databases:

• Google Scholar: Broad initial searches for relevant papers.
• IEEE Xplore, ACM Digital Library, and SpringerLink: Focused searches for technical and peer-reviewed studies.

Filters were applied to achieve the following:

• Focus on articles published between 2015 and 2024 to ensure relevance to current technologies.
• Limit results to English-language publications.

2.3.4. Step 4: Screening Titles and Abstracts

Titles and abstracts were reviewed to exclude irrelevant studies. Papers were included if they discussed scalability, security, feasibility, or user control in centralised or decentralised IdM systems. Both theoretical and practical studies were included to ensure diverse perspectives.

2.3.5. Step 5: Full-Text Review and Supplementation

A detailed review of the selected papers was conducted to ensure relevance and depth. Additional papers were identified manually by examining references from key studies or incorporating known seminal works. This iterative process ensured comprehensive coverage of the field.

2.4. Final Selection of Papers

After this process, ~90 papers were identified as relevant for the review. These papers provide a balanced representation of decentralised and centralised IdM systems, focusing on their respective strengths, challenges, and future potential.

3. Key Concepts and Technologies

3.1. Centralised Identity Management Terminologies

• Single Sign-On (SSO): SSO is a feature that allows users to log in once to a system and gain access to multiple trusted services, without the need to authenticate again. It enhances user experience by reducing the number of times the user needs to log in and validate their identity. The central authority manages the authentication of the user identity and issues a token that grants them access to different services [12].
• Identity Provider (IdP): The IdP is a central authority in a system that manages user identities, stores their credentials, and handles authentication processes. Its main function is to validate the user’s identity and issue a token or assertion through which the user can access the application [12].
• Service Provider (SP): An SP is an application or service that relies on an IdP to authenticate users. Once the identity is validated by the IdP, the SP grants access to its resources based on the user’s permissions and roles [12].
• Access Control: This is a process to define and enforce rules and policies on what and how much access to specific resources in a system a user can obtain after authentication. It involves verifying the user’s identity and determining what permissions or roles they have, allowing access to services and data based on those rules [12].
• Authentication Server: The Authentication Server is responsible for validating user credentials during the login process. It works with the IdP to verify credentials entered by the user and ensures that the user is who they claim to be before granting access to requested resources [13,14].
• Single Point of Failure: It is a critical component in a system whose failure disrupts the whole system. It could be a centrally located server or database on which multiple users are dependent. This disruption could lead to complete unavailability of the system or service [14].
• Role-Based Access Control (RBAC): This method manages and regulates access for users based on their roles. Through this, user access can be limited by specifying what and how they can utilize the service. This enhances security and restricts unauthorised access [13,15].
• Trust Management: In organizational setups where multiple domains or entities are involved, the process of trust management helps establish relationships among them. It involves exchanging security tokens, metadata, and public keys to ensure that users and SPs can verify each other’s authenticity [12,13,14].
• Multi-Factor Authentication (MFA): MFA enhances security by requiring users to authenticate using more than one method, such as a combination of something they know (password), something they have (security token), or something they are (biometrics). It adds an additional layer of protection to centralised identity systems, helping prevent unauthorised access [12,13,15].

3.2. Decentralised Identity Management Terminologies

• Self-Sovereign Identity (SSI): SSI refers to a model where individuals have full control over their identity without relying on central authorities. Users gain full rights to manage and share their identity data directly with the SP, enhancing privacy and autonomy in identity management [16].
• Blockchain: It is a decentralised, distributed digital ledger where all records, transactions, or data are stored across multiple computers, ensuring security and maintaining integrity without needing a single central authority [17].
• Distributed Ledger Technology (DLT): DLT allows recording data and transactions in multiple places (nodes) rather than storing it centrally, reducing the risk of a single point of failure [17].
• Decentralised Identifiers (DIDs): DIDs are globally unique identifiers used in decentralised blockchain systems, allowing users to be validated without needing a central authority, enhancing system privacy [17].
• Verifiable Credentials (VCs): VCs are digital versions of physical identity documents like passports or driver’s licenses, stored in digital wallets and issued by trusted authorities. They are used to validate and share a user’s identity, disclosing only necessary information to third parties [18].
• Consensus Mechanism: A process that ensures all participants agree on the validity of a transaction, maintaining data integrity and preventing tampering. Common mechanisms include Proof of Work (PoW) and Byzantine Fault Tolerance (BFT) [17].

4. Understanding Centralised Identity Systems

Centralised identity management systems (CIMSs), also referred to as traditional identity management systems (see Figure 2), are commonly implemented in environments where a single entity manages all user identity-related tasks. This entity is called an identity provider (IdP) and is responsible for storing credentials and handling authentication requests. This model is widely used by businesses where managing user access rights and maintaining control over identity is crucial for enhancing operations [12,13].

In such systems, users generally pass their credentials to the central server, and after the central server validates them from its stored data, it grants or denies access to services accordingly. This central server keeps control over user information, personal data (name, sex, age, DOB, address, etc.), credentials and logs of all transactions [12,14]. In the following subsections, we briefly summarise the inner workings of centralised authentication and review the popular centralised identity management systems.

4.1. Inner Workings of Centralised Authentication

All centralised identity management systems have several key components, such as identity providers (IdPs), which store and manage identity data; service providers (SPs), the applications or services that users interact with, acting as a bridge between the user and the IdP; an Authentication Server, which handles authentication requests (approving or denying access); and the single sign-on (SSO) feature, which allows users to access multiple applications with a single authentication [14]. The process of authentication in a centralised architecture is straightforward and can be understood as follows (see Figure 3):

• The user, through the SP (application or service), submits credentials to the IdP.
• The IdP validates the credentials and generates an authentication token.
• The authentication token, having approval and scope of access, is sent to the SP, which grants access to the resources.
• The user can access the services without the need to re-authenticate, as the token serves as proof of identity for a specified duration [12].

The CIMS provides consistency and simplicity in its approach by centralising user administration, enforcing policies across all SPs, and minimising the management cost associated with administering distributed systems.

4.2. Federated Identity: Connecting Multiple Domains

CIMSs prove to be efficient in single-domain systems. However, in cases where multiple organizations are involved, an enhanced version of the CIMS extends to Federated Identity Management (FIM). In FIM, each organization has its own IdP to share resources and authenticate users across domains (see Figure 4). This model allows interoperability between organizations while retaining the centralised nature of identity management [12,19].

A trust broker helps to manage trust relationship between organizations. Each organization’s IdP registers themselves with the trust broker, which maintains metadata about each entity. The trust broker ensures that organizations registered with it trust each other’s authentication token. Some common protocols that are used in federated systems are SAML (Security Assertion Markup Language), OpenID, and OAuth [13].

This approach helps build scalable systems and provides easy access for users. However, it also introduces an additional layer of complexity in trust management. The metadata need to be dynamically updated between organizations to ensure that this relationship remains secure without affecting any connected user or their data [12,19].

4.3. Security Considerations

The identity includes sensitive details such as the user’s name, age, bank details, and other personal information, which, if accessed by unauthorised individuals, could be misused. Therefore, ensuring its security is of paramount concern. Several mechanisms are employed to keep identity data and the transactions involving these data secure:

• Encryption: Identity data such as credentials and session tokens are encrypted both in transit and at rest to prevent unauthorised access [12,15].
• Access Control: Strict policies are enforced centrally, allowing access only to resources based on the roles and permissions of the user. Role-based access control (RBAC) ensures that the user is granted permissions as per their assigned roles. These are managed by the identity provider (IdP) and enforced across all service providers (SPs) [12].
• Session Management: Tokens issued after authentication are time-limited and need to be refreshed after a specified time. This reduces the risk of session hijacking [12,13].
• Logging and Monitoring: Centralised servers allow for easy collation and storage of audit trails, including transactions, authentication attempts, and access requests. These logs help monitor suspicious activity and aid in debugging issues in centralised identity management systems (CIMSs) [12].

4.4. Challenges and Drawbacks

While centralised identity management systems (CIMSs) offer significant operational benefits, they also present some inherent limitations:

• Single Point of Failure: Since the central point of control in the CIMS is the identity provider (IdP), the entire system depends on the availability and security of the IdP. If the IdP becomes inaccessible due to security breaches, network failures, or maintenance issues, the entire system becomes unavailable to users [12,13].
• Scalability: Although the CIMS is highly scalable, as the number of users grows, so does the amount of data. Managing large volumes of user identity data and authentication requests can become a challenge for organizations. This increase can lead to delays and higher loads on the authentication infrastructure [12].
• Lack of Flexibility: Centralised systems face integration issues with new security protocols and evolving decentralised identity systems. Any upgrade requires significant reconfiguration, making them less adaptable to environments that need to quickly upgrade their security infrastructure.
• Privacy Risks: Since all user data are stored centrally, the system becomes an attractive target for attackers. If data are compromised, attackers can gain access to the identities of all the users in the system [12,20].

4.5. LDAP: The Directory-Based Approach

Lightweight Directory Access Protocol (LDAP), initially created by the University of Michigan, is a simplified network protocol designed to access and manage directory information. LDAP’s operational foundation is based on a client–server model, where the client requests resources and the server serves those requests. The protocol achieves efficiency by transmitting only necessary data, bypassing many of the complex mechanisms inherent in the X.500 Directory Access Protocol (DAP). As a result, it has become essential for managing user data and network resources, particularly in environments where directory services must operate effectively across a range of devices, including those with limited processing capabilities [21,22].

LDAP is a directory-based identification service used in systems such as Microsoft Active Directory (AD), owing to its responsiveness and capacity to manage network resources. Its hierarchical structure allows quick data retrieval, authentication, and user authorisation [23]. Consistency in LDAP is achieved by using LDAP commands to manage AD objects, such as creating and changing user and computer records. Furthermore, LDAP directories are designed to store user email addresses and distribution lists in corporate email systems, simplifying email routing and improving organizational collaboration [24].

4.5.1. Technical Architecture

Some main components of LDAP’s client–server model are the Directory System Agent (DSA), a server component that manages the Directory Information Tree (DIT) and runs the LDAP service, and the Directory User Agent (DUA), a client-side component that interacts with the DSA to retrieve and update directory information. Each entry in the LDAP directory is uniquely identified by a Distinguished Name (DN) and Relative Distinguished Names (RDNs), which indicate levels within the DIT hierarchy [21].

4.5.2. LDAP Authentication Process

The LDAP authentication procedure can be broken down into the following steps [21,23,25]:

• Client Request Initiation: The process starts when the client sends a bind request to the LDAP server, providing the Distinguished Name (DN) and the password.
• Bind Operation:
  • Simple Bind: The client sends the DN and password in plaintext. This method is insecure unless SSL/TLS is used.
  • SASL Bind: The Simple Authentication and Security Layer (SASL) framework is employed to provide secure authentication mechanisms.
• Server Verification: The LDAP server verifies the credentials by comparing the provided password with the one stored in the directory.
• Search Operation: Upon successful verification, the server searches the Directory Information Tree (DIT) for the corresponding entry of the authenticated user.
• Response to Client: The server responds to the client indicating whether the authentication was successful or not. If successful, the client is granted access to the directory services requested.
• Post-Authentication Actions: Once authenticated, the client may perform actions like reading, modifying, or deleting entries in the directory, as allowed by their permissions.

4.5.3. Security of LDAP

LDAP provides several advantages for managing user identity and authentication, such as streamlining user administration and access control, while also offering a hierarchical structure that simplifies directory entry organization and retrieval. LDAP’s interoperability ensures compatibility across different systems and platforms.

However, LDAP is not without its flaws. One significant security issue is that LDAP transmits credentials in plaintext by default, posing a serious security risk unless SSL/TLS encryption is employed. Moreover, LDAP configurations can be complex, requiring careful planning and execution. As directory sizes grow, scalability concerns can lead to performance degradation. As such, it is crucial to address LDAP’s inherent security risks [26,27].

4.5.4. Addressing Vulnerabilities Using LDAPS (SSL/TLS)

One way to mitigate LDAP’s security vulnerabilities is through the use of LDAPS, which encrypts LDAP traffic via SSL/TLS. This protects sensitive information from tampering or eavesdropping. The LDAPS process starts with an SSL/TLS handshake, initiated when the client connects to the LDAP server on port 636. The server responds by sending its digital certificate, which the client verifies. Once the certificate is validated, an encrypted session is established, ensuring that all subsequent LDAP operations, including the bind request, are conducted securely over this channel. Additionally, strong access control policies, regular security audits, and LDAP activity monitoring can further safeguard the integrity of both system and user data [28,29].

4.6. RADIUS: Remote Authentication Dial-In User Service

RADIUS is a protocol designed to provide centralised authentication, authorization, and accounting (AAA) services for users accessing network resources, such as VPNs and WLANs [30]. It operates over the User Datagram Protocol (UDP), using port 1812 for authentication and port 1813 for accounting. RADIUS follows a client–server architecture, where the Network Access Server (NAS) functions as a client, routing user access requests to the RADIUS server [31].

The centralised server manages the user’s identity, the extent of their access, and logs all activities. Communication between the client and server is secured using a shared secret and a private key, unique to each pair, which encrypts the communication between them. The protocol employs various types of packets, each distinguished by a unique code. For instance, Code 1 represents an access request from the client requesting authentication, Code 2 indicates successful authentication, and Code 3 is used to deny access [32]. Each packet contains fields such as Code, Identifier, Length, Authenticator, and several other attributes [31,33].

When a client seeks authentication, it sends an Access-Request packet containing the username and password, encrypted using a pseudo-random Request Authenticator, the shared secret, and MD5 hashing. The server decrypts the password and, based on the validation result, responds with Code 1, 2, or 3, indicating the status of the authentication. RADIUS sends accounting packets to log session data and acknowledges them with Accounting-Response packets. It is versatile and can be integrated with EAP, LDAP, and Active Directory [33]. RADIUS is widely deployed in enterprise environments, using implementations like FreeRADIUS, Cisco Secure ACS, and Microsoft’s IAS/NPS to support wired, wireless, and remote access needs [30,31,34].

RADIUS: Security and Limitations

The security of RADIUS is primarily dependent on the use of a shared secret key and the proper generation of the Request Authenticator. However, as cyber threats have evolved, the use of a stream cipher with MD5 for password encryption is now considered weak, exposing the protocol to potential attacks [33,35]. Attackers can exploit Access-Request packets to target the shared secret, and if they obtain both the Access-Request and server response, the Response Authenticator can be compromised. Additionally, insufficient randomness in the Request Authenticator can lead to both active and passive attacks, such as Denial of Service (DoS) [33].

4.7. SAML: Security Assertion Markup Language

SAML is an open standard for sharing authentication and authorization information between identity providers (IDPs) and service providers (SPs). When used with single sign-on (SSO), SAML allows users to authenticate once and then access all trustworthy applications within a domain without having to log in again. Once the user is validated, XML-based assertion tokens are generated, containing authentication information that enables SPs to grant access to resources. This protocol is crucial in contexts where secure and seamless access to remote services is required [36].

Once validated by the IDP, the SP uses the SAML assertion token, which typically contains authentication statements, attribute statements, and authorization decision statements. This token then provides access to services for the user [37].

4.7.1. SAML: Technical Architecture

The working mechanism and architecture of SAML involves several steps (see Figure 5):

• When a user seeks to access the resources, the SP will initiate an authentication request and redirect it to the IDP with a SAML request object containing the authentication context [37].
• When the validation is completed, a SAML response is generated and returned to the user. This SAML answer specifies both the claim and the scope of access. The user automatically sends the claim to the service provider (SP), who validates digital signatures and allows access to services [16].
• Each SAML assertion is digitally signed and the transactions between these parties (user, SP, and IDP) are all carried out over HTTPS, which makes the communication secure and prevents any eavesdropping or man-in-the-middle attacks [37].
• The SP maintains each session to prevent the misuse of assertions, thereby mitigating the risk of session hijacking [37].

4.7.2. SAML: Limitations

SAML and SSO are commonly used together, but implementing them can be difficult and time-consuming [16]. Configurations must be carefully managed to prevent risks related to the IDP, SP, and cryptographic keys. Furthermore, since SAML relies on a central authority (IDP), it creates a significant vulnerability [37].

4.8. OAuth2.0: The Open Authorization Standard

OAuth is one of the most popular authentication models and is utilised by organizations like Google, Microsoft, Facebook, and Instagram [38,39]. It allows access to client data without the need to share user credentials with third-party applications [40]. The OAuth framework addresses the issue of misuse of client credentials by supplying time-bound access tokens and limiting the credentials shared with third-party apps [40]. By employing cryptography, these tokens are secured, mitigating the risk of token misuse during issuance or exchange [41].

4.8.1. Key Components

The main components of the OAuth architecture are as follows:

• Resource Server: Stores protected data. By processing requests from third-party apps, it provides access to these data after validating the permissions in the access tokens [38].
• Resource Owner (User): The person or entity that owns the data. They have the right to decide who can access and what part of the data can be accessed [38,42].
• Client: The third-party app that asks for access to the protected data on behalf of the resource owner.
• Authorization Server: This is where the resource owner approves or denies access requests. Access tokens are issued here [43].

4.8.2. Process of Requests Flow in OAuth

The process flow in OAuth involves several steps (see Figure 6):

• Request Initiation: The user uses the client app to call the “/authorize” endpoint on the Authorization Server to initiate a request to access the protected resources [42,44]. The client app constructs the URL, typically including parameters such as
  • response_type=code
  • client_id=CLIENT_ID
  • redirect_uri=REDIRECT_URI
  • scope=read write
  • state=UNIQUE_STATE
• Authorization Request: After the request reaches the Authorization Server’s authorization endpoint, it logs the request and grants permission accordingly [42].
• Authorization Code: Once approved by the resource owner, an authorization code is generated and returned to the client app along with a unique state [42,43].
• Code Exchange: The client app sends a POST request to the Authorization Server’s token endpoint, exchanging the authorization code for an access token [42].
• Token Usage: The client app accesses the protected resources using the access token.
• Resource Access: Upon receiving the request with the token, the resource server validates the token using a public key and checks parameters such as validity, scope, and expiration [43].
• Refresh Token: As the access token has limited validity, the client app can request a refresh token from the Authorization Server if needed [42,43].

4.8.3. Limitations and Mitigations

OAuth has a few security flaws which makes it prone to attacks like replay attacks, CSRF attacks, implementation faults, misconfigurations, and authorization code interception. To some extent, they can be avoided by utilising strategies like stronger encryption techniques to prevent token misuse, Unified Client App Type to decrease complexity and use of digital signatures, and 2FA for added protection [44].

A few common vulnerabilities and its mitigation [45,46] are as follows:

• Excessive Scope Requests: Many applications request more information and access than necessary, such as location data, which raises privacy concerns. This issue can be mitigated by encouraging developers to request limited scopes for their apps functionality and by implementing strict policies and standards that promote low-scope usage.
• Lack of User Control: Manipulative UI designs often lead users to grant all requested permissions without proper consent, allowing more access than necessary. To mitigate this, fine-grained permission control should be implemented, enabling users to select specific scopes of access. Additionally, user-friendly authorization screens should clearly display the requested scopes in a straightforward manner.
• Token Replay Attacks: Here, the attacker obtains unauthorised access to resources by intercepting and reusing the OAuth token. To mitigate this, the tokens should have a smaller time span and should be immediately revoked if misuse is discovered.

5. Understanding Decentralised Identity Systems

The existing model of identity management heavily relies on centralised systems, where the management and control is being regulated and governed by a single entity with the user having very little control over it. While decentralised systems aim to remove this central control, many still depend on trusted parties or governance frameworks to ensure system integrity, manage updates, and handle conflicts, indicating that complete independence from trusted intermediaries is not always achieved.

Various studies have been conducted to analyse and demonstrate how blockchain and decentralised frameworks can be utilised to address the shortcomings in a CIMS. The DIMS model allows users to have full control over their identity, deciding whom to share it with, as well as managing its storage and security [47]. The use of blockchain’s DLT in relation to the SSI model [48] makes the entire process more transparent. This transparency is achieved through SSI, which stores cryptographic proofs that are available at any time and are trusted by all parties [49].

Each user in the SSI environment is given a unique DID and is connected to a key pair that the user can manage directly through a mobile or web application (depending on the product used). The user’s public key is shared on the DLT and associated with an identifier, permitting users to independently verify identities [50]. Users can now prove their attributes with the help of VCs, which can be cryptographically confirmed by other parties without the need for a central authority. The verifying party uses publicly accessible data related to the identifier and credential issuer to confirm the validity of the credentials [51].

5.1. Architecture

• Decentralised Identifiers: DIDs are unique identifiers created using cryptographic key-pairs. The public key is published on the blockchain, while the private key remains securely with the user. Documents containing service endpoints and public keys required for interactions are mapped to DIDs (see Figure 7) [52,53].
• Blockchain and Distributed Ledger Technology: The system utilises DLT to ensure security, immutability, and transparency. To maintain confidentiality, only minimal information like DID documents or attestations is stored on-chain. Personal data remain off-chain, with the blockchain holding links to these data and proofs of transactions [53,54].
• Credential Issuance and Verification: Trusted issuers provide users with verifiable credentials, which are cryptographically signed and stored in the user’s digital wallet. When needed, users present these credentials for identity verification. Moreover, Zero-Knowledge Proofs (ZKPs) enhance privacy by enabling users to prove specific attributes without revealing full credential details [55].
• Role of SSI: Following the principles of SSI, users own and control their identities via digital wallets that hold their DIDs, private keys, and verifiable credentials. This empowers users, ensures transparency, and prevents identity theft prevalent in centralised systems [45,53].
• Agent-Driven Interoperability and Privacy Protection: Identity agents manage complex interactions for users, making transactions secure and private. Advanced cryptographic methods like ZKPs and selective disclosure allow users to authenticate themselves and disclose specific attributes without exposing actual data [55].
• Revocation and Persistence: The system contains methods that allow issuers to revoke credentials before they expire. Verifiers can instantly check revocations using the blockchain. Persistence is guaranteed through backup methods, enabling users to restore their identities and credentials even if keys are lost [53].

5.2. Interoperability and Standards

Even in decentralised systems, there are often specific entities or groups that handle important tasks, like issuing credentials or verifying transactions. This helps keep the system stable and secure, striking a balance between decentralisation and trusted oversight. Additionally, the systems must adhere to standards such as verifiable credentials and W3C’s DIDs, making them compatible and leading to higher adoption rates [56,57]. Following these standards will ensure that the DIMS can be implemented regardless of the platform used for verification or issuance.

However, creating compatibility between centralised and decentralised identity systems presents major hurdles. This disparity is mainly due the use of different technologies altogether from storage, validation, and transmission of requests. One way this can be standardised is via the use of an AP, which can enable cross-platform communication and bridge technologies.

5.3. Security and Privacy Considerations

DIMSs are designed to promote user privacy and prevent centralised authorities from controlling people’s identities. These systems must be extremely secure, employing strict standards to preserve data and assure the accuracy of identity-related actions. Advanced encryption ensures the security of user information. Some decentralised models also take a “privacy-by-design” approach, utilising technologies such as ZKPs and selective disclosure. This enables users to verify their identities without disclosing their actual details [51,55].

Although safe to some extent, the DIMS also has several weaknesses. In a DIMS, users are the owners of their identity, which is secured through encryption. The owners are responsible for keeping their private keys. If the key is lost, there is no central authority to assist in revoking or recovering the key [58,59].

5.4. Hyperledger Indy

Hyperledger Indy is a blockchain-based DIMS platform that provides SSI by spreading different transaction types onto discrete ledgers with independent topologies. It is based on a small, regulated network of validators monitored by stewards who use a BFT consensus mechanism to ensure the system’s integrity [60]. Indy uses features like ZKPs, allowing users to validate credentials without providing sensitive information. Hyperledger Indy was created with the goal of promoting trust, security, and compliance with rules such as GDPR [61,62].

5.4.1. Technical Architecture

Indy’s key components include validators, stewards, the DLT, DIDs, ZKPs, and the Plenum consensus algorithm. Validators are the essential nodes in charge of maintaining the distributed ledger. These validators keep the system running and consistent by validating and adding transactions to the blockchain, safeguarding the system’s integrity. Indy uses multiple blockchains each for specific purposes across its network: the Domain Transactions (Domain TXs) blockchain manages domain-specific data and transaction metadata; the Pool Transactions (Pool TXs) blockchain manages validator setups and operations; and the Config Transactions (Config TXs) blockchain stores the updates to network parameters and policies [63].

As a permissioned network, Indy handles transaction validation and ledger maintenance via steward-managed validators. Indy is designed to be distributed across several virtual machines and is generally containerized with Docker to facilitate management. The fault-tolerant Plenum consensus algorithm supports dynamic configuration modifications, but its scalability is limited by the computational requirements of its trust-based consensus mechanism. Transaction latency varies with the number of validators and transaction rates, and write latencies are consistently lower than read latencies [63].

5.4.2. Limitations

While scalability has traditionally been a challenge for Hyperledger Indy due to its consensus mechanism, recent advancements have made significant strides in this area. The introduction of new consensus methods, like the “Indy Besu” project—which leverages a modular system compatible with both permissioned and permissionless networks—demonstrates a commitment to improving transaction throughput and flexibility [64]. These developments are promising for handling a larger number of users and transactions. However, some challenges remain, for example, the network’s performance can still be affected as usage scales up, particularly due to the voting process required for adding new validators. Additionally, the open-source code for Indy remains restrictive, and the complex deployment process can pose obstacles for enterprises considering its implementation [61,63].

5.5. Sovrin

The Sovrin Network is an open-source DIMS designed to provide self-sovereign identities (SSIs) to individuals, organizations, and devices. Built on the Hyperledger Indy framework, it leverages blockchain technology to offer a secure, user-centric approach to digital identity management. Its uses Redundant Byzantine Fault Tolerance (RBFT) which keeps the Sovrin Network operational even in cases when some nodes fail to respond. This increases stability and ensures the ecosystem remains fault tolerant. Additionally, it has its own token/currency, known as SOV, which is awarded to validators as an incentive for authenticating and managing identity operations of the Sovrin Network [65].

5.5.1. Technical Architecture

The architecture of the Sovrin Network consists of four distinct layers:

The Ledger layer maintains identity-related information such as DIDs, credential definitions, and revocation registers. Stewards verify transactions using a consensus process built on the RBFT algorithm. This ensures the data’s confidentiality and integrity [65].

The Agent layer facilitates secure, peer-to-peer connections. Edge and cloud agents manage the exchange of digital identities and credentials via the encrypted DIDComm protocol. This layer helps to maintain privacy and security for the communication of identity-related data between user, organization, and within the network [65,66].

The Governance layer is governed by the Sovrin Governance Framework (SGF). The SGF sets policies and standards for the system to be compliant with legal, security, and privacy requirements. The set guidelines are followed by all participants of the system, to maintain trust, autonomy, and security of the Sovrin ecosystem [65].

5.5.2. Limitations

Despite its robust architecture and capabilities, the Sovrin Network has some limits. One of the key issues is its reliance on established organizations, such as stewards, who serve as the intermediary between consumers and the distributed ledger. While this strategy improves security and governance, it adds a layer of complexity and dependency, potentially undermining the network’s claim to be truly decentralised. Furthermore, Sovrin’s scalability, portability, and connection with other identity systems are still in early phases of development, raising worries about broad acceptance. In addition, certain users may struggle to handle the Sovrin Network’s complicated design and governance mechanism [65,66].

5.6. Blockstack

Blockstack’s ecosystem is built on the Bitcoin blockchain, which is well known for its security and global acceptability. It plays a crucial role in the ordering of operations and binding of digital identities to public keys. It employs the Blockchain Name System (BNS) instead of the traditional Domain Name System (DNS), which links public keys to human-readable names and allows users to control additional data. A VirtualChain acts as an abstraction layer, allowing Blockstack to run independently of the underlying blockchain, increasing speed and flexibility while keeping complexity out of the blockchain. The Atlas network, which is a peer-to-peer network, handles data finding and indexing. Gaia, Blockstack’s decentralised storage system, securely stores data that are signed with the user’s private key to provide security and keeps data tamper-proof. Gaia also works with existing cloud services like Dropbox and Amazon S3 [67].

5.6.1. User Registration, Authentication, and Key Revocation Process

The user registration process in Blockstack involves a two-phase procedure:

The first process begins with the user preordering a name, which generates a hash that is kept on the blockchain. After a mandatory waiting period, the name is linked to the blockchain, completing the registration process. The name is cryptographically connected to the blockchain’s public key. This ensures that every name is unique and secure. Names are registered in certain namespaces, which determine the cost and renewal procedures for the names. The blockchain stores these namespaces as part of the identity management procedure [67].

Then, during the authentication process, Blockstack uses an SSO system in which each user enters their Blockstack ID, which is uniquely linked to a public key via blockchain. When a user submits the appropriate private key as proof of ownership, they are authenticated. This method protects and authenticates a user’s identity without relying on centralised systems [68].

Blockstack’s key revocation approach is beneficial when keys are lost. The name transfer process allows users to transfer ownership of their Blockstack ID to another address. When the key is revoked, all subsequent operations on the connected name are disabled, protecting the user’s identity from unauthorised access [67].

5.6.2. Strengths

Blockstack distinguishes itself from other products through features such as pricing functions, recovery from blockchain forks, and cross-chain migration. The pricing functions are designed to manage the supply and demand of names through dynamic pricing, where more desirable names demand higher prices. The recovery mechanism for blockchain forks helps prevent inconsistencies by detecting and correcting the state based on consensus hashes. Cross-chain migration allows the transfer of identities across different blockchains in the event of a blockchain failure, offering robustness and adaptability [67,68].

5.6.3. Limitations

Although Blockstack’s model addresses many concerns, certain issues remain. The shift of data storage from the blockchain to Gaia, while primarily aimed at enhancing scalability, still presents significant challenges. The inherent overhead associated with encryption, decryption, and signature verification processes may impact performance in scenarios requiring real-time processing. Additionally, the system’s complexity, with its multiple layers—comprising the blockchain, peer-to-peer network, and storage system—presents management challenges. Furthermore, large-scale deployment would require specialists for setup [67,68].

5.7. uPort

uPort is an open-source solution based on the Ethereum blockchain. Its architecture is based on Ethereum smart contracts, which control identity generation, management, and recovery. These smart contracts guarantee that all identity-related transactions on the Ethereum blockchain are secure, transparent, and irreversible. The uPort mobile app saves the user’s private key on their smartphone and serves as a link between the user and the contracts. Users can ensure security and privacy by keeping the private key on their personal device [69].

When a user generates an identity, two smart contracts are generated on the Ethereum blockchain—“controller” and “proxy”. The proxy contract serves as a unique, persistent identification that communicates with other contracts on the blockchain network. It adds a layer of abstraction between the user’s private key and the blockchain, allowing for key recovery while preserving the identity’s integrity. The proxy contract collaborates with a controller contract, which maintains access control and allows users to authenticate themselves to the proxy contract. This technique assures that the user’s identity is protected even if the private key is lost or compromised [70].

In the instance of key loss, a Recovery Quorum Contract is used. This is controlled by a group of trustworthy individuals (recovery delegates) who assist in regaining control of the identity. This decentralised recovery mechanism for user identities is a critical element of uPort since it allows users to reclaim their identity without relying on a centralised authority [70].

uPort uses both on-chain and off-chain data handling. Smart contracts handle essential identification functions on the blockchain and uPort identities can be linked to off-chain data saved on decentralised storage platforms such as IPFS. The data maintained off-chain comprise profile information, attestations, and other identity-related qualities that are cryptographically connected to the uPort identity via a Registry Contract. This way, the owner receives complete control over their data, resulting in a secure and private manner to handle identity [69].

Limitations

The main limitation of uPort is the system’s dependence on Ethereum, which means that it is subject to the network’s scalability and transaction costs. The off-chain storage of sensitive data, while secure and gives users a sense of ownership, still requires trust in the chosen storage solution. The issue of portability and interoperability may arise since it is primarily based on Ethereum. Also, given uPort’s reliance on smart contracts, a malicious node could trace and link activities tied to a uPort ID, which may potentially expose users identity and actions, compromising their identity [69,70].

5.8. EverID

EverID, built on a permissioned Ethereum blockchain, is designed for managing digital identities and facilitating secure financial transactions across multiple currencies. EverID is not open-source and operates within a controlled environment to ensure privacy and security in its transactions. In the EverID system, a user does not necessarily need a mobile device, as the government ID, biometric information, and third-party certifications that make up the digital identity can all be stored in the cloud [71].

5.8.1. Architecture

The key components of EverID’s architecture include the EverID Datagram, Decentralised Application (DApp), Application Programming Interface (API), core smart contracts, the Ethereum blockchain, and super nodes. Biometric identifiers are used to create unique user identities, which are stored in the Datagram system on both user devices and super nodes. The DApp facilitates self-registration and identity management, the API ensures secure integration with other services, and the core smart contracts manage identity creation, validation, and transactions [72].

5.8.2. Limitations

EverID also functions as a self-sovereign identity (SSI) and value transfer system, allowing users to control how their data are shared. However, this is not fully realised, as users are required to disclose all their information when verifying a claim, which does not adhere to the principle of data minimization [71]. Additionally, since EverID operates on a permissioned Ethereum blockchain, access is restricted to approved participants, introducing a level of centralisation. As the number of transactions and users increases, it could lead to higher operational costs, slower transaction speeds, and could negatively affect user experience and the overall efficiency of the EverID ecosystem.

5.9. ShoCard

ShoCard is a identification and authentication platform based on public Bitcoin blockchain. Here, users’ identity information is stored on blockchain in the form of signed cryptographic hashes. The information is verified by third parties who have verified the user’s identity using the blockchain. Users’ private information is not kept in a storage or central location, and they can authenticate or prove account ownership without having to disseminate bits of their identity across many services [73].

ShoCard uses blockchain and cryptographic hashes to securely link a user identifier with an existing trusted credential, such as a passport or driver’s license, along with additional identity data [71,74].

5.9.1. ShoCard Architecture

It operates through a three-phase process: bootstrapping, certification, and validation (see Figure 8) [71].

• In the bootstrapping phase, the ShoCard mobile app generates a cryptographic key pair and scans the user’s credentials. These user credentials are encrypted with the data and stored as signed hash in a Bitcoin transaction. The unique ShoCardID serves as a reference point on the blockchain.
• In the next phase, certification, users interact with SPs to add verified attributes to their identity, which are hashed, signed, and stored on the blockchain.
• During the validation phase, a relying party retrieves and verifies these certifications by checking signatures and comparing the data against the blockchain records.

5.9.2. Limitations

ShoCard’s system relies on a central server, introducing a level of centralisation that could compromise its decentralised design. If ShoCard ceases operations, users could lose access to their identity data. Additionally, the lack of omnidirectional identifiers may hinder its expansion into broader ecosystems, and the inherent delay in Bitcoin transaction confirmations could pose issues when real-time user validation is required [71,73].

6. Comparison

The comparative analysis of various standards and protocols from existing research on identity management and authentication models focused on five major factors: scalability, reliability, security, adaptability, and cost. These factors provide essential insights for any organization, big or small, when planning to deploy, invest in, use, and choose between centralised (see

Table 1. Comparison of centralised identity management protocols.

Factor	LDAP	OAuth	RADIUS	SAML
Purpose	Directory access protocol for querying and modifying directory services [21,22]	Authorization protocol to grant third-party access without exposing credentials [40,41]	AAA for network access [30,33]	SSO for secure authentication between identity providers and service providers [36]
Authentication Mechanism	Username- and password-based authentication [23,25]	Access tokens for delegation [38]	Username and password, often paired with EAP for stronger authentication [33]	Based on user assertions exchanged between identity providers and service providers [37]
Authorization	Uses role-based access control with permissions in the directory [23]	Access tokens for scope and permissions [40]	Coupled with authentication, includes service type and IP parameters [33]	Based on user assertions, used for authorization across different services [36]
Encryption and Security	LDAP communication can be secured with TLS/SSL, but credentials are often transmitted in plaintext [23,27]	Relies on HTTPS for transmission security and token encryption [40,41]	Can use TLS to secure communication; credentials are encrypted [30]	Uses XML-based encryption, with HTTPS ensuring secure message exchanges [16,37]
Scalability	Scales well for large organizations with complex directory structures [24]	Scalable for web apps and third-party services [40]	Suitable for large enterprise networks with distributed authentication needs [31]	Federated model supports scalability across multiple service providers [37]
Vulnerabilities	Credentials can be exposed if not encrypted, risks of data leaks [23,27]	Vulnerable to token misuse and scope overreach if not properly configured [46]	Susceptible to replay attacks and configuration errors [33]	Prone to misconfigurations, possible XML-related vulnerabilities [16,37]
MFA	Can be integrated with other mechanisms such as OTP or biometric for added security [12]	Often integrated with two-factor authentication methods [40]	Supports integration with MFA systems such as EAP [33]	Supports MFA to strengthen SSO, integrating additional verification steps [16]
Integration	Limited integration with modern web-based applications [23]	Integrated with modern web applications using REST APIs [38,40]	Supports integration with enterprise-grade network systems [30]	Integrated with web-based applications using SAML assertions [37]
Protocol Base	TCP/IP protocol, uses specific directory protocols [21,22]	HTTP-/HTTPS-based protocol, relies on REST APIs and JSON or XML for token transmission [38,40]	Operates over User Datagram Protocol (UDP), supports EAP for authentication [33]	XML-based protocol, relies on SOAP, HTTP, and HTTPS for secure message exchanges [37]
Use Cases	Used in enterprise environments for directory services [24]	Web and mobile applications, API access delegation [41]	Network access control in enterprise environments [31]	SSO for enterprise environments, academic institutions, and government services [16,37]

) and decentralised (see

Table 2. Comparison of decentralised identity solutions.

Parameter	uPort	Sovrin	EverID	Blockstack	ShoCard	Hyperledger Indy
Blockchain Type	Ethereum (Public) [70,72]	Hyperledger Indy (Consortium) [61,65]	Proprietary Blockchain (EverChain/ Private) [71,73]	Bitcoin Blockchain (Public) [68,69]	Bitcoin Blockchain (Public) [71,74]	Hyperledger Indy (Consortium) [61,65]
Identity Management	SSI [70]	SSI [66]	Centralised and decentralised components [71]	Decentralised Identity [68]	SSI [71]	Self-sovereign identity (SSI) [61]
Interoperability	Supports interoperability through DIDs [70]	Uses open standards like DID, VC, and DKMS [66]	Limited, mostly within EverID ecosystem [71]	Limited to Blockstack ecosystem [68]	Limited, mostly within ShoCard ecosystem [74]	Supports interoperability through DIDs [61]
Scalability	-	-	Centralised control with some decentralised features [71]	Full control over identity and data [68]	Full control over identity data [74]	Full control over identity data [61]
User Control	Full control over identity data [70]	Full control over identity data [66]	-	Full control over identity and data [68]	Full control over identity data [74]	Full control over identity data [61]
Cost	-	Off-chain, with DID on-chain [66]	Hybrid (on-chain and off-chain) [71]	Off-chain, with minimal on-chain data [68]	Off-chain [74]	Off-chain [61]
Data Storage	Off-chain [70]	Off-chain, with DID on-chain [66]	Hybrid (on-chain and off-chain) [71]	Off-chain, with minimal on-chain data [68]	Off-chain [74]	Off-chain [61]
Use Cases	General-purpose identity management, DApps [70]	Identity management, enterprise solutions [66]	eGovernment, healthcare [71]	Decentralised apps, digital assets [68]	Enterprise identity management [71]	Identity management, enterprise solutions [61]
Cryptographic Methods	Elliptic Curve Cryptography (ECC) [70]	Zero-Knowledge Proofs, ECC [66]	ECC, AES encryption [71]	ECC, Proof of Work [68]	ECC, RSA encryption [74]	Zero-Knowledge Proofs, ECC [71]

) identity systems.

6.1. Scalability

Scalability is one of the primary concerns for any system that is, or in the future will be, expected to serve the growing demands of users or organizations. Centralised systems like OAuth and LDAP are still widely used and have proven to show significant strength in this regard. Even with complex directory structures, these systems allow for vertical and horizontal scaling by adding more resources to the central server as demand increases. SAML’s federated model allows it to scale across multiple domains, making it a favourable approach where SSO is needed. OAuth and other centralised models support integration with web applications or third-party services and are effective in handling large volumes of token-based access. Over time, these systems have become optimised with existing hardware and server configurations; however, reliance on a single point of control can sometimes introduce bottlenecks as the system grows.

For decentralised systems, scalability challenges are rooted in the distributed architecture and consensus mechanisms. For example, Ethereum, used by uPort, has a current transaction throughput of 15–30 TPS, with layer-two solutions like Optimistic Rollups and zkRollups potentially increasing it to 1000–4000 TPS [2,17]. Blockstack leverages Bitcoin’s Proof of Work (PoW), inherently limited to approximately 7 TPS due to the computational requirements of mining. By comparison, Hyperledger Indy uses Redundant Byzantine Fault Tolerance (RBFT), which achieves scalability with up to 300 TPS in practical implementations while maintaining resilience to up to 33% node failures [18]. Recent developments such as Indy Besu propose leveraging smart contract modules on permissioned and public blockchains to further scale identity operations while ensuring consistency across systems. Centralised systems, like LDAP, can scale horizontally by adding servers, achieving response times under 200 milliseconds for up to 10,000 queries per second in well-optimised environments [62].

6.2. Reliability

Reliability is another factor where centralised and decentralised systems differ fundamentally in their approach. Centralised identity systems ensure reliability through well-defined failover mechanisms and high-performance servers. LDAP, for instance, achieves redundancy by employing multi-master replication, allowing backup servers to take over within seconds during outages, with a downtime of less than 1% annually in most enterprise environments [2]. However, such setups are vulnerable to single points of failure, with catastrophic failures reported in high-profile attacks, such as the Microsoft Azure AD outage in March 2021 that lasted several hours [62]. Decentralised systems like Hyperledger Indy offer enhanced reliability through fault-tolerant consensus mechanisms like RBFT, which can maintain network functionality even with up to 33% node failures [18]. Additionally, distributed networks reduce the risk of complete outages but may experience temporary synchronisation delays when nodes are added or updated.

On the other hand, decentralised systems are built on distributed networks which makes them fault tolerant. Systems like Sovrin or Hyperledger Indy continue to work even if individual nodes fail, so the risk of the complete system going down is prevented. Also, RBFT used in some of these models increases reliability by ensuring consensus even in the presence of faulty or malicious nodes. Decentralised models are complex and may potentially have synchronisation delays but prove to be much more resilient.

6.3. Security

Security is paramount in identity systems, and here, both systems present different kinds of advantages. LDAP uses SSL/TLS to encrypt credentials exchanged between client and server, ensuring secure transmission. OAuth relies on HTTPS for secure token exchanges, with tokens issued with a TTL, reducing the risk of reuse after expiration. SAML secures credentials using XML encryption and transmits authentication assertions over the network. These centralised systems use established encryption protocols, providing robust security during transmission and storage. However, the reliance on a central server creates vulnerabilities. If compromised, sensitive data can be exposed, as seen in the 2021 Facebook breach, where over 533 million user records were leaked [62]. Additionally, attacks like brute force or token replay remain risks if not mitigated through strict configurations.

Decentralised systems employ advanced cryptographic features to address these vulnerabilities. uPort uses selective disclosure, sharing only necessary information, such as confirming age without revealing a birthdate. Sovrin and Hyperledger Indy employ ZKPs to enhance privacy, enabling users to prove identity without exposing unnecessary personal details. These systems follow SSI principles, storing data on distributed ledgers. Blockchain’s immutability ensures that data, once written, cannot be tampered with. Furthermore, the absence of a central repository reduces the impact of potential breaches.

However, decentralised systems also have risks. Vulnerabilities in BFT consensus, like RBFT used in Indy, may allow delays or collusion among malicious nodes/citeref17. Additionally, bugs in smart contracts can lead to unauthorised actions or manipulation of identity data. Key management is another challenge; loss or theft of private keys could result in irreversible loss of access. Scalability-related issues, such as increased latency with high transaction volumes, can also indirectly affect the security and performance of these systems [2,18].

6.4. Adaptability

Adaptability reflects how well these systems integrate with existing infrastructures and adapt to future needs. Centralised systems like LDAP, SAML, OAuth, and RADIUS are inherently adaptable due to decades of use in enterprise environments. LDAP’s directory-based control scales effortlessly to support millions of users with minimal overhead. OAuth and SAML provide APIs and libraries that integrate smoothly with enterprise systems like SSO and cloud platforms, making them a go-to choice for organizations seeking rapid deployment. Their compatibility with widely used infrastructure reduces the time and complexity of integration [62].

In contrast, decentralised systems like Sovrin, uPort, and Hyperledger Indy face unique challenges in adaptability. These systems often require middleware to bridge the gap between blockchain operations and traditional IT environments. For example, integrating Hyperledger Indy with existing enterprise databases involves creating custom APIs or plugins that enable compatibility with distributed ledgers. Public blockchain-based models like uPort, built on Ethereum, face additional constraints such as reliance on gas fees and transaction throughput, which limit real-time adaptability. In contrast, private blockchain systems, such as Sovrin and Hyperledger Indy, provide more control over operations, making them somewhat more adaptable for large-scale enterprises. However, transitioning from centralised to decentralised models demands significant infrastructure upgrades and retraining of IT teams to manage distributed systems, adding complexity and cost [2,18].

6.5. Cost

Cost is a critical factor in evaluating identity systems, with centralised and decentralised models showing stark differences. Centralised systems like LDAP, SAML, and OAuth are highly cost-efficient. Initial setup costs for small and medium organizations typically remain below USD 10,000, while operational costs are limited to infrastructure maintenance and periodic updates. Open-source tools and extensive vendor support further lower the total cost of ownership. LDAP’s scalability and minimal hardware requirements reduce recurring costs, making it ideal for enterprises with fixed budgets [62].

Decentralised systems, however, require significantly higher financial investments. Private blockchain networks like Sovrin and Hyperledger Indy necessitate validator node maintenance, with setup costs of USD 5000–USD 10,000 per node. Overall deployment for decentralised networks can range from USD 10,000 to USD 50,000 depending on scale and complexity. Public blockchain-based systems, such as uPort on Ethereum, incur operational costs tied to network activity, with gas fees averaging USD 1–20 per transaction during peak usage. These costs can escalate in high-frequency identity verification scenarios, making such systems less feasible for organizations with cost-sensitive operations. Additionally, decentralised systems require expertise in blockchain, forcing organizations to invest in retraining employees or hiring specialists, which further increases operational costs [17]. Consequently, decentralised systems are often adopted by large organizations with long-term strategies focused on decentralised control and compliance with privacy regulations.

7. Conclusions

This article reviews various identity management systems based on both centralised and decentralised models. A thorough comparison of the most prominent models of both systems on the basis of scalability, reliability, security, adaptability, and cost is conducted. The analysis revealed that both the systems have some advantages and disadvantages. The organizations need to make informed trade-offs between scalability, cost-effectiveness, security, and complexity, based on their requirements.

Currently, centralised systems, which have been used for decades for authentication and identity management, are the preferred choice as they provide both organizations and users ease of setup, management, and cost effectiveness. These systems handle large-scale deployments swiftly without the need for much changes in the existing infrastructure. Additionally, centralised systems have adapted to modern-day threats by implementing MFA and encrypted sessions which add complexity for attackers.

On the other hand, decentralised systems address the shortcomings of the centralised systems. Its innovative approach to distribute the control of identity management in the hands of user and other participants, making the system secure and transparent. However, it faces a huge setback because of its complex architecture, which also needs a huge investment for setup and maintenance. There is a need for specialists in this field to handle these operational challenges. Industries like healthcare, finance, and government, which operate and store identity data and require high levels of security and privacy, can benefit from a decentralised approach. Blockchain scalability solutions like sharding and making use of the layer-two approach could further reduce the operations cost and increase performance and overall efficiency of the decentralised systems.

8. Future Scope

The future of identity management could lie in a hybrid approach that combines both methods. Centralised systems can become more efficient by adding features from decentralised systems such as enhanced security and privacy through APIs or some other integration methods. Scalability and ease of management in centralised systems could make decentralised systems more efficient, overall enhancing user experience and making the whole process more practical. Additionally, utilising Zero-Knowledge Proofs (ZKPs) with centralised methods, where user receives more control on what data they want to share and with whom can enhance security. Well-known products like Yoti and Earth-ID are already pioneering this hybrid approach, creating an environment that can integrate seamlessly with existing services without much changes.

Looking forward, decentralised systems need to be optimised to reduce their latency and improve transaction throughput. As blockchain evolves and transaction costs decrease, decentralised models may become more feasible, potentially reshaping the way authentication and identity management is performed completely.