Skip to Content
GuideIntroduction
View .md

Alien Solana SSO: On-Chain Human Verification for dApps

Alien Solana SSO links Solana wallets to verified Alien IDs through on-chain attestations. Unlike standard SSO, which issues JWT tokens, it records the wallet-to-identity link directly on the Solana blockchain, where any program or dApp can read it.

How Wallet Linking Works

  1. Your code — the user connects their Solana wallet to your dApp.
  2. SDK handlesgetAttestation() checks whether the wallet already has an on-chain attestation. If it does, the wallet is already linked and the flow ends here.
  3. SDK handlesgenerateDeeplink() returns a deep link and a polling code.
  4. Your code — display the deep link as a QR code, or redirect mobile users to it.
  5. The user approves the linking request in the Alien App.
  6. SDK handlespollAuth() polls until the SSO server returns the oracle-signed payload. The oracle is the Alien-operated Ed25519 signing service that authorizes attestations; its signature is verified on-chain when the attestation is created.
  7. SDK handlesbuildCreateAttestationTransaction() assembles the attestation transaction locally from the polled fields — the server never returns a pre-built transaction.
  8. Your code — ask the user’s wallet to sign the transaction.
  9. Your code — send the transaction. Once it lands on-chain, the wallet is linked to a verified Alien ID.

Single-platform provider. Solana SSO currently uses a single-platform-provider model. The signing oracle is pinned to one configured platform provider, and the /solana/attestation endpoint returns 404 unless the caller’s provider address matches it. Attestations bind a wallet to the platform’s Alien ID — not to your individual dApp. Third-party dApps can still read attestations directly on-chain by deriving the attestation PDA (Program Derived Address) instead of calling /solana/attestation — see Derive Attestation PDAs.

Linking is not authentication. An existing attestation proves the wallet was linked to an Alien ID at some point — it is not proof that the current visitor controls the wallet. If you need to authenticate the user, additionally verify a fresh wallet signature server-side; the SDK does not provide that primitive.

Who Should Use Solana SSO?

  • The platform provider linking Solana wallets to verified Alien IDs via the SSO service
  • Solana dApps and programs that need provable verification that a wallet is linked to a verified Alien ID — by reading the on-chain attestations directly (via PDA derivation)

Install

# Core SDK for vanilla JavaScript/TypeScript npm install @alien-id/sso-solana # For React projects npm install @alien-id/sso-solana-react

Attestation Lifecycle and Re-Linking

Wallet binding is one-shot: the on-chain programs initialize the session and Solana entry PDAs with init, so only one attestation can exist per wallet at a time. A second attestation attempt for the same wallet fails with an account already in use error — you will hit this when reusing wallets in dev/test. To re-link a wallet, the wallet owner must first close the existing attestation with the wallet-signed close_attestation instruction.

On-Chain Programs

Solana SSO interacts with three on-chain programs:

ProgramID
Credential Signer9cstDz8WWRAFaq1vVpTjfHz6tjgh6SJaqYFeZWi1pFHG
Session RegistryDeHa6pyZ2CFSbQQiNMm7FgoCXqmkX6tXG77C4Qycpta6
SAS (Solana Attestation Service)22zoJMtdu4tQc2PzL74ZUT7FrwgB1Udec8DdW4yw4BdG

These programs handle session creation, verification, and attestation storage on Solana.

Attestations are created through the official Solana Attestation Service programs, so they are fully SAS-compatible — discoverable and verifiable via SAS-compatible explorers, and interoperable with other Solana attestation-based applications.

Each link is stored as three connected records:

  • Session Entry — created in the Session Registry program
  • Solana Entry — maps the Solana address to the session
  • Attestation — created in the SAS program

The attestation PDA is derived from the credential, the schema, and the user’s public key; the session entry derives from the session address and the Solana entry from the wallet address. The session address is the on-chain address of the user’s Alien session record — the same identifier that appears as the sub claim in standard SSO tokens.

Next Steps

Last updated on