identiblok.
Get started for free

IDENTIBLOK DOCUMENTATION

Your app. Your users. Their wallets.

Prepare for wallet authentication and permissions on the Identiblok blockchain.

Authentication and authorization, together.

Authentication establishes which wallet a person controls. Authorization decides what that identity can do in your application. Identiblok’s product direction combines wallet sign-in with permissions recorded on its own blockchain.

Wallet authentication and chain integration are in development. The developer workspace can save application drafts today. There is no released wallet SDK or live permission API to integrate yet.

Developer workspace accounts currently use a separate account service. That account login is distinct from the wallet authentication being built for your application’s users.

Prepare an application

AVAILABLE IN YOUR WORKSPACE

Give your application a starting point.

Application name
A name you recognize in your developer workspace.
Application origin
Your website’s HTTPS scheme, hostname, and port if needed. Do not include a path, query, or fragment. A trailing slash is removed when saved.
Sign-in return URL
An exact HTTPS URL on the same origin where the user will return after sign-in. Wildcards and fragments are not accepted. Paths and query values retain their spelling.
Example draft configuration
{
  "name": "Your application",
  "app_origin": "https://app.example.com",
  "redirect_url": "https://app.example.com/auth/callback"
}

Saving these settings does not prove domain ownership, activate wallet sign-in, or write to the blockchain. Never enter seed phrases, private keys, passwords, or access tokens.

PLANNED AUTHENTICATION FLOW

A signature starts the session.

  1. The application requests a challenge. The challenge must bind a one-time nonce to the application, its origin, the intended network, and a short expiry.
  2. The wallet asks for consent. The person sees which application is requesting sign-in and approves the chain-native signature. A sign-in signature must not authorize a transfer or permission change.
  3. Identiblok verifies the proof. Signature, wallet identity, request binding, expiry, and replay protection must pass before a session can be issued.
  4. The application establishes a session. Sessions must be scoped to the application and support expiry, revocation, and key recovery. A wallet address supplied by the browser is never sufficient proof.

The signature encoding, wallet interface, and verification rules will follow the native Identiblok chain protocol. These requirements are a design outline, not a published wire format.

Signing in is not permission to do everything.

The planned authorization service resolves permissions within the application’s namespace using the Identiblok chain. Applications must check those permissions on their server before each protected action.

Granting or revoking a permission is a separate administrative operation. It requires an authorized actor and explicit confirmation. A user’s sign-in signature never grants that user a role.

Permission checks must account for finalized state, revocation, key rotation, and unavailable or stale chain data. The finality and freshness policy depends on the chain’s protocol and must be settled before launch.

What must be ready before launch.

  • A documented Identiblok test network, wallet interface, and signature test vectors.
  • Verified application ownership and exact origin and return-URL registration.
  • Replay-resistant sign-in and revocable sessions with tested recovery behavior.
  • Permission isolation between applications, authorized role changes, and revocation tests.
  • Tests for chain outages, stale responses, forks, and invalid proofs.
  • A reviewed privacy model that keeps personal information and session secrets off-chain.
Security model