Proof of wallet control
Sign-in must verify a fresh, application-bound challenge using the Identiblok wallet protocol. An address alone is not authentication. Users must never share seed phrases or private keys.
SECURITY & TRUST
Prove identity. Check permission.
Wallet ownership and application access are separate checks. Both need a clear boundary.
The wallet and blockchain integration is in development. The requirements below describe the target security model, not a completed audit or a live authentication service.
Permissions scoped to your app
Each permission must belong to a specific application and identity. Role grants and revocations require a separately authorized administrator; signing in must never create privileges.
Sessions that can end
Short-lived sessions, one-time challenges, key rotation, and revocation are required parts of the design. Permission checks must reject unavailable or insufficiently fresh chain state.
Personal data off-chain
The intended design keeps profiles and session secrets off-chain. Wallet identifiers and permission records may still be public or linkable; their visibility and recovery model need review before launch.
What protects the developer workspace today.
Developer account access uses a dedicated account provider. Application drafts belong to the account that created them. Server checks and database row-level policies enforce ownership, and saves check for conflicting edits. These controls protect setup records; they do not implement blockchain authentication for your app’s users.
The chain has a specific job.
Identiblok’s blockchain is intended to supply verifiable permission state. It does not replace secure application code, session handling, recovery, or server-side authorization. A valid signature does not prove a person’s real-world identity.
The chain protocol, finality model, wallet verification, and permission lifecycle must be documented and tested before live customer authentication is enabled.
Review the developer guide