Web3 SSO and Decentralize Hosting with Internet Computer Protocol ∞

Abstract

Internet Identity offers a seamless Web3 Single Sign-On (SSO) experience, allowing users to authenticate across various ICP dApps without needing usernames or passwords. In this article, learn how Principal IDs connect Cycle Wallets, Ledger Account IDs, and deployed dApp Canisters. Dive into the decentralized hosting model of ICP and understand how canister ownership is managed and controlled. We also discuss common challenges in implementing SSO with Micro-Frontend Architecture and provide developer insights on building decentralized applications using ICP tools.

Identity

Self-sovereign single sign-on (SSO) solution for dapps

Internet Identity (II) is the first thing you will find interesting as you start developing solutions on this network. In other conventional Web2 systems, developers have to integrate services like Auth0 , Microsoft Entra Community , and Amazon Cognito for identity and access management. Meanwhile, end users of these services must install authenticator apps on their mobile devices.

However, when it comes to Internet Identity, things become much simpler. End users do not have to worry about complex authenticator app setups, remembering passwords, or the need for an external password manager as an overhead.

Internet Identity holders can store private keys securely on the hardware of their trusted devices (such as mobile devices). It acts more like a Mobile PassKey. Therefore, end users do not have to deal with passwords; they can simply unlock their mobile devices using a PIN code/ pattern/ or biometric authentication to authorize secure interactions with the dApps hosted on the Internet Computer Protocol (IC). All they need to do is ensure they have an active mobile internet connection and enable Bluetooth on their devices to access the SSO facility throughout the Internet Computer Protocol Network.

The whole process is simple and browser-oriented, eliminating the hassle of downloading and installing external apps. If a device is changed or lost, users can easily add a Recovery Phrase, unlike in other Web3 identity wallets, and they can also add a recovery device. Their signing keys are permanently stored in secure hardware and controlled by their biometrics.

In conventional Web2 systems, remembering a username is another struggle when signing up for and using different web services. While most cases consider email addresses as usernames, a person may have multiple email addresses, such as one from their academic institution, one provided by their office for accessing various office facilities, and perhaps an organizational email address from a fellowship or membership in different organizations. Additionally, personal email addresses may also be used. Using these email addresses as usernames can create challenges, as this data is often sold to various email marketers, leading to annoying newsletters and promotional emails for end users.

In contrast, with the Internet Computer, identity is represented by just a seven-digit number. This means users do not have to worry about data privacy when signing up for a new dApp in the ICP network.

Mr. Bj?rn Tackmann from DFINITY covered a full lecture on Identity and Authentication. Watch the video ??.

Principal IDs

When users sign up with their Internet Identity at any dApp, they are identified by Principal IDs, which act like Universally Unique Identifiers (UUIDs). However, it's important to note that these do not remain the same across different dApps, as their domain names will be different.

Note: The Principal ID generation process is primarily linked to the Internet Identity unique number and the dApp's domain address through which the Frontend Canister can be accessed.

When a user tries to sign up or sign in to a dApp in IC, the frontend redirects the user to the Internet Identity page, unlike other SSO services. There, the user can use their Internet Identity number and secret credential from their mobile device, enabling two-factor authentication. If the user signs up for the first time, a unique Principal ID is generated for that user in that specific dApp. Under that domain address, every action the user takes in that dApp can be identified by that Principal ID.

Users get a unique Principal ID for each dApp they sign up for, allowing them to maintain separate balances and identities across different applications. Even when creating a new wallet, a new Principal ID is generated, ensuring assets and data are isolated, providing enhanced privacy and control across the ICP network.

Though this principal id can't hold any balances by itself but have some vital role beyond just being the unique identifier. As we know in Web3 ecosystem paying transactions fees with utility tokes (gas fees), ensuring smart contract ownership and managing wallet balances with these web3 identities are some of the core operations. Principal IDs are majorly responsible for these type of operations.

In the diagram we can see that I principal id can be linked with different functionalities.

• Canister Controller: One of them is Canister Controller. This will be described In the decentralized hosting section in detail.
• Account Id: Another important element is the Ledger Account ID. This account ID is derived from the account owner's principal, and each account can only be owned by one principal. Since the principal ID cannot hold any type of balances, the Ledger Account ID holds token balances, such as ICP tokens, which can be considered digital assets or currencies. The user who controls their principal ID can perform token transactions with the associated Ledger Account ID [Reference].
• Cycle Wallet: The last one is the utility token balance. The Principal ID is also linked to the Canister Address, which acts as the Cycle Wallet. This allows users or dApp owners to add and manage Cycles, keeping the canister running. As running a dApp in ICP requires Cycle Tokens, which cover computation costs.

Web3 transforms hosting by shifting from centralized corporation control to decentralized hosting. dApps run on blockchain networks, with computational costs covered by Cycle Tokens in the ICP network. By separating utility and native tokens, ICP stabilizes costs, pegging Cycle Tokens to the IMF’s XDR to avoid market fluctuations, ensuring predictable, affordable costs for long-term dApp development [Reference].

Hosting dApp in ICP and SSO Challenges

The Internet Computer Protocol (ICP) is a secure and transparent blockchain-based network designed to host data and programs. However, the concept of hosting data and programs as dApps differs from that of most other current blockchain networks.

In most chains, only smart contracts are hosted at the on-chain level. The other components of the application, such as the frontend and third-party integration components, are considered Web2 and may be hosted on different cloud servers. In contrast, one of ICP's primary objectives is to free the hosting industry from the control of large tech corporations and bring it under the decentralized nature of Web3.

By hosting both frontend and backend elements on the blockchain, ICP creates a more cohesive and integrated ecosystem, where traditional cloud-based architecture is replaced by smart contracts.

With this goal in mind, ICP introduced two types of canisters in its ecosystem: Frontend Canisters and Backend Canisters.

Frontend Canister

Frontend Canister is a way to put the user interface directly on the blockchain. This means that web applications can have their entire frontend code (HTML, JavaScript, CSS, etc.) served from canisters rather than relying on traditional web servers or centralized cloud hosting. [Reference]

A frontend canister that communicates with backend canister(s) to provide a full-stack dApp.

One of the bright sides is that these frontend canisters can interact with both Web2 and Web3 backends. For Web2, there is a specific instruction that developers should keep in mind: whitelisting the domains. For example, if your frontend canister is pulling text-based-data/ dynamic data from backend canisters (on-chain), but requires images or other media data, it is necessary to use external on-chain storage solutions like IPFS or off-chain storage like an S3 Bucket. In this case, the frontend engineer should whitelist the relevant domains/IPs from the frontend canister. This whitelist file can be found at the following directory location:

<FRONTEND-CANISTER-ROOT>/public/.ic-assets.json5        

Micro-Frontend Architecture Challenges with Internet Identity

As we mentioned in the previous section, a Single Internet Identity holder can have different Principal IDs if they sign up for different dApps hosted under various domain addresses. This can present challenges for applications that have Multi-Frontends in their architecture.

While ICP supports alternative frontend origins, this solution is primarily focused on whether the same frontend canister can be discovered through multiple domain addresses. In the case of Micro-Frontends, the frontend canisters are separate applications designed to fulfill distinct responsibilities.

In scenarios like this, the architect should keep in mind the following considerations while designing the Backend Canisters. Managing requests from multiple frontends through a single backend canister can create difficulties for user identity management (KYC/KYB) and tracking a user's digital footprint. This is because different frontends will provide different principal IDs for a single Internet Identity holder.

Why is Micro-Frontend Required at ICP Blockchain Network? The answer to this question depends on factors such as the project's size, scalability among sub-nets, team count, business logic, and concerns related to decentralized ownership of UI components. From the perspective of the ICP frontend context, a significant limitation to keep in mind is that a frontend canister can host roughly 1 GiB of static files. It is recommended to distribute your files across multiple canisters if the total size of all your assets begins to exceed this limit [Source].

Backend Canister DeHosting

The Smart Contract of the ICP network deployed inside Backend Canisters. These hosted smart contracts on the blockchain and can be responsible for any backend logic. These contract's interface are transparent (not the implementation), anyone can search a canister detail from the the ICP dashboard by their canister ID.

Example: Click here to view Cycles Ledger Index Canister where the controller principal ID, Hosted Subnet ID, and Public Method names and required arguments are available. At the Canister Interface section the source code of that canister can be also viewed. The Module Hash can be found in this Dashboard which can be helpful to detect if the contract's implementation gets upgraded.

Canisters can be much more transparent if they are designed to be controlled by a DAO using the SNS (Service Nervous System).

Backend and Frontend Canister Integration Helping Tool at ICP

ICP has enabled their Backend Canister with HTTPS outcalls to interact with Web2 API services and Inter-canister calls to allow different backend services to be deployed as microservices. However, integrating backend and frontend canisters requires a different approach. Unlike Swagger, ICP uses Candid UI, which provides frontend developers with endpoint details for integrations. It employs a canister interface description language stored in a file with a ".did" extension. Because this requires a new syntax, there is a dApp at IC named "Canlista: Candid binding generator" that helps developers generate and format the interface description language from their desired programming languages.

Another one is "Live Candid UI", which provides a consistent view of a service, regardless of whether the underlying backend canister program is written in Rust, JavaScript, or any other programming language.

Developers often use this tool while developing the canister in their local environment. However, once a backend canister goes live on the mainnet, it can be challenging for the frontend to identify the endpoints and arguments correctly. This is why this dApp is recommended, as the entire Candid UI is hosted live on the ICP MainNet. All we need to do is add the query parameter to the end of the URL for our desired backend canister ID.

How canister ownership are ensured at ICP DeHosting?

As mentioned above a Principal ID is tied with three responsibilities. Linking the Cycle Wallet ID, the Ledger Account ID, and owning Canisters as a Controller. The Canister Controller is how ownership is maintained in this decentralized hosting network of ICP.

When the development and deployment process for a dApp begins, a developer identity must be created at the hardware level (on the developer's device or in the server environment). An associated Principal ID will also be generated under that Identity. Consequently, when a dApp is deployed using that hardware-level Internet Identity, its associated Principal ID will automatically become the canister's controller.

Note: To maintain the security, privacy and access control at B2B level Brain Station 23 relies on Amazon Web Services (AWS) cloud servers as a deploying device.

So, if anyone has access to the device or server that holds the private key of that identity, they actually own the canister. By using that device, the canister implementation can also be upgraded.

Additionally, if anyone wants to add their dApp-generated Principal IDs as controller generated through browser interaction via Internet Identity and the dApp's domain address that is also possible. To assign this, the command needs to be executed from the deployed device, with the targeted Principal ID passed as a parameter. [Reference]

dfx canister update-settings --set-controller <TARGET-PRINCIPAL-ID> <DAPP-CANISTER-ID>        

This type of customization is necessary when dApps have roles such as Super Admin or System Admin, where only the Canister Controller can perform specific actions from the frontend.

Reviewed by: Yamin Raad , Antonin Islam