Are you an LLM? Read llms.txt for a summary of the docs, or llms-full.txt for the full context.
Clear Signing – 1auth
Skip to content

Clear Signing

Clear signing shows the 1auth transaction, message, or EIP-712 review iframe before the user approves the browser or platform passkey prompt. Use it when the user should inspect the action in 1auth instead of relying only on your app's own UI.

Clear signing is useful for wallet dashboards, account tools, high-risk transfers, EIP-712 approvals, and any flow where independent review is more important than the fastest possible signing ceremony.

Default behavior

Blind signing is the SDK default. That means supported signing calls hide the 1auth review iframe unless you opt into clear signing.

Set blind_signing: false on the client or wallet-client factory to show the 1auth review UI by default.

Authentication, signup, recovery, and permission-grant dialogs are always visible when required. The blind_signing option only controls signing review UI.

Configure OneAuthClient

Opt into clear signing when you initialize OneAuthClient.

import { OneAuthClient } from "@rhinestone/1auth";
 
export const client = new OneAuthClient({
  providerUrl: "https://passkey.1auth.app",
  clientId: "wallet-dashboard",
  blind_signing: false,
  sponsorship: {
    accessTokenUrl: "/api/sponsorship/access-token",
    extensionTokenUrl: "/api/sponsorship/extension-token",
  },
});

Supported signing calls from this client now show the 1auth review iframe before WebAuthn starts.

Supported methods

Clear signing applies to SDK signing flows that can render a 1auth review iframe:

  • sendIntent()
  • sendBatchIntent()
  • signMessage()
  • signTypedData()
  • signWithModal()
  • createPasskeyWalletClient() signing and sendCalls() flows

It does not change authWithModal(), signup, login, recovery, or permission-grant dialogs.

Per-call overrides

You can override the client default for a single request.

await client.signMessage({
  username: "alice@example.com",
  message: "Approve checkout order #123",
  blind_signing: false,
});

This is useful when most of your app uses blind signing, but selected high-risk actions should still show the review UI.

For viem wallet-client integrations, set blind_signing: false on the factory because it creates its own internal OneAuthClient:

const walletClient = createPasskeyWalletClient({
  accountAddress,
  clientId: "wallet-dashboard",
  chain,
  transport,
  blind_signing: false,
});

What users see

The 1auth review iframe renders the signable action before WebAuthn:

  • verified actions from 1auth's clear-signing registry,
  • decoded ERC-20 transfers and approvals when possible,
  • app-supplied ABI labels marked as app supplied,
  • raw contract calls when no safe decode exists,
  • chain, amount, recipient, and policy details when available.

Verified badges only come from 1auth's registry. App-supplied ABI metadata can make a custom contract readable, but it is not marked verified.

Blind-sign selected calls

If a clear-signing client has a low-risk flow where your app already shows the full payload, you can hide the 1auth review UI for that one request:

await client.sendIntent({
  accountAddress,
  targetChain: 8453,
  calls: [
    {
      to: merchantAddress,
      data: transferCalldata,
      value: "0",
    },
  ],
  blind_signing: true,
});

Use this sparingly. When blind_signing: true, your app is responsible for presenting the payload, amount, recipient, chain, and risk context before calling the SDK.

Dashboard example

Configure clear signing on the shared client for account or wallet UI.

oneauth-client.ts
export const oneAuth = new OneAuthClient({
  providerUrl: "https://passkey.1auth.app",
  clientId: "wallet-dashboard",
  blind_signing: false,
});
send-payment.ts
await oneAuth.sendIntent({
  accountAddress,
  targetChain: 8453,
  calls: [paymentCall],
  tokenRequests: [usdcRequest],
});

The user reviews the action in 1auth, approves the browser passkey prompt, and the SDK continues with intent execution.

Failure behavior

Clear signing still requires a valid passkey signing context.

Common cases:

  • no active passkey session: ask the user to sign in with authWithModal(), then retry the signing call,
  • untrusted or unregistered app origin: complete the visible trust flow before signing,
  • WebAuthn cancellation or platform failure: surface the SDK error and let the user retry from your app UI.

Clear signing vs Headless Mode

Clear signing still uses 1auth's passkey signer. The iframe is visible, and the user's passkey produces the signature after review.

Headless Mode is different: your app provides signatures from another validator or signer, and 1auth does not run the passkey signing dialog at all.