PairKey Get started →

DOCS / QUICKSTART: OAUTH/OIDC

Quickstart: OAuth/OIDC

Use an OAuth/OIDC identity to approve an exact message with PairKey’s hosted signers. The configured browser example uses Google OIDC; ordinary off-chain signing needs no Solana wallet or registration transaction.

PairKey requires an issuer-signed OIDC ID token bound to a short-lived Ed25519 key. An OAuth access token by itself does not authorize a PairKey request. Other providers need their issuer, audience and HTTPS verification keys pinned by the operator.

Open the live demo → Select OAuth / OIDC as the source. The Google browser flow is a preview; account selection has been observed, while an end-to-end Google-authorized signature is still awaiting live acceptance. Access depends on the Google OAuth app’s publishing status and test-user list. This option appears when the operator has enabled Google in /api/v2/config.

Try one exact message

  1. Select a Google account. PairKey uses Google’s stable subject identifier, issuer and this site’s client ID to establish your namespace.
  2. Choose Solana, EVM, Zcash, NEAR or Bitcoin and a path, then load the derived public key.
  3. Write a message of at most 256 UTF-8 bytes and select Prepare Google approval.
  4. Continue with the same Google account again. This second ID token includes a fresh nonce tied to your namespace and a short-lived Ed25519 key. Both signers independently verify the token and the exact request before signing.
  5. Inspect the signature and receipts, then select Verify signature. Message signing does not broadcast a destination transaction.

Why Google appears twice

The binding includes the identity’s subject, which is learned at first sign-in. The first token selects the namespace; it cannot approve signing. The second token must name the same subject and carry the nonce derived from the bound ephemeral key. In this demo, a fresh key and token are requested for each message. The private key stays in browser memory; hosted v2 sessions are deferred.

Only the public recovery record is saved in this browser tab. Neither Google ID token nor the ephemeral private key is written to the audit trail or recovery storage. After a reload, recover a submitted job from its saved public record; prepare a new request if no job was submitted.

Integrate your own application

Use the browser SDK and your own Google Web OAuth client. Configure your site as an authorized JavaScript origin, and have the PairKey operator pin your exact issuer, client ID audience and HTTPS JWKS URL. The audience is part of the namespace identity: changing the client ID changes derived keys. No Google client secret belongs in browser code.

Use Google Identity Services to select the subject, call pairkey.onboard(undefined, {identity: {Oidc: {issuer, audience, subject}}}), and create ephemeralIdentity(namespace) before preparing the request. Ask Google for a fresh ID token with ephemeral.oidcNonce; pass that token to ephemeral.approve(prepared, key, {idToken}). Save the public recovery record before requesting the token or submitting the job. See the SDK sequence and policy management.

Optional rules and costs

Google login authorizes an exact message even without saved rules. Optional PairKey rules are stored on Solana and independently read by both signers. Editing those rules requires a separate Solana fee payer and transaction; the fee payer does not become the OIDC identity owner. Ordinary off-chain message approval sends no Solana authorization transaction. Service and destination costs are separate.