Skip to main content

Portal-Managed Backups

Portal lets you securely back up your users’ MPC wallets so they can recover their wallets even if their device is lost or damaged. By default, Portal encrypts and stores both backup shares (β€œPortal-Managed Backups”):
  1. The client backup share is encrypted on the user’s device, with the encryption key stored using their chosen backup method (Google Drive, Password, Passkey, or Firebase Auth). The encrypted share is then stored by Portal.
  2. The custodian backup share is encrypted and stored by Portal, with the encryption key stored in our KMS infrastructure.
By default, Portal manages storing both the encrypted client backup share and the custodian backup share for you. If you prefer to store and manage the backup shares in your own infrastructure instead of using Portal-Managed Backups, see our Self-Managed Backups guide.
Both the client backup share and the custodian backup share are necessary to recover a Portal wallet.

Backup Methods

You can choose one or more backup methods for storing the encryption key for the client backup share.

Passkey + Enclave

Your Portal clients can create a passkey to authenticate and manage the private encryption key within a secure enclave.

Implementation Requirements

  1. Initialize the Portal class with a passkey object.
  2. Call backup with the Passkey backup method argument.

Custom Domain Passkeys

By default, Portal handles passkey operations through our hosted domain (portalhq.io). If you want passkeys to be associated with your own domain (e.g., yourapp.com), you can configure a custom relying party. Benefits of using your own domain:
  • Passkey prompts display your domain name instead of Portal’s
  • Users see a consistent brand experience
  • Passkeys are portable across your applications that share the same relying party
Setup Requirements
To use your own domain for passkeys, you’ll need to:
  1. Configure DNS - Point your passkey subdomain (e.g., passkeys.yourapp.com) to Portal’s infrastructure
  2. Provision a TLS certificate - Create a certificate for your subdomain that Portal will store in our secure enclave
  3. Configure CORS - Allowlist your application origins
Getting Started: Reach out to the Portal team for instructions on setting up a custom domain, including TLS certificate provisioning for our enclave.
Configuration
Once your custom domain is set up, configure your passkey options:
Step 1: Create a Passkey
Create a passkey for your user. This can be done separately from the backup flow:
Step 2: Create a Backup
Once a passkey exists, you can create a backup and store the encryption key with it:

Password/PIN

Your Portal clients can create a password/PIN. They can either remember the password or store it in a password storage manager.

Implementation Requirements

  1. Create a UI for password input.
  2. Enforce password requirements. Customer can choose between password, PIN code, passcode, or any other text-based input.
  3. If the user forgets their password, there are no additional recovery options.

Google Drive

See the docs on how to set up Google Drive.

Firebase Auth Backup

Allow customers to use their existing Firebase Authentication to authenticate into a secure enclave that holds the encryption key for the user. The Portal Web SDK uses Firebase ID tokens to store and retrieve encryption keys from Portal’s token backup service (TBS). This is ideal if your web app already uses Firebase Auth β€” no additional authentication method is required from your users. See the Firebase Auth Backup setup guide for prerequisites and Firebase project configuration.

Implementation requirements

  1. Integrate Firebase Authentication in your web app (for example with the Firebase JavaScript SDK).
  2. Call portal.configureFirebaseStorage with a getToken callback that returns a Firebase ID token for the signed-in user, or null when no user is signed in.
  3. Run backup with BackupMethods.firebase only after Firebase storage is configured and the user is signed in.
Unlike React Native, the Web SDK does not use a separate @portal-hq/firebase-storage package. Firebase backup is built into @portal-hq/web via configureFirebaseStorage. Your app supplies Firebase Auth; the Portal iframe requests ID tokens from the parent page through a secure postMessage bridge.

Configure Firebase storage

Call configureFirebaseStorage before backupWallet or recoverWallet with BackupMethods.firebase. You typically do this immediately before the backup or recovery flow, or once after the user signs in to Firebase.
The user must be signed in to Firebase before running backup or recovery. If there is no signed-in user, getToken should return null and the operation will fail.
The tab examples below assume a portal instance and configureFirebaseForPortal helper from the Configure Firebase storage section above.
Ensure the user is signed in to Firebase, configure storage, then run backup. With Portal-Managed Backups (the default), Portal stores the encrypted client backup share for you.
Related documentation