V Is For Verification: Verify Before Approve

Defining Verify Before Approve (VBA)

Verify Before Approve (VBA) functions as an architectural pattern that mandates a distinct, cryptographically signed proof of user intent for high-value operations.

Unlike standard authentication flows where a session cookie grants broad permission for a set time, VBA requires the user to re-authenticate or perform a specific verification action tied directly to the payload of the request.

The pattern ensures that even if an attacker successfully hijacks an active browser session, they cannot authorize a transaction because they lack the ability to present the required cryptographically bound signature generated by a local FIDO2 authenticator.

This control effectively shifts the trust boundary from the broad session identifier to the specific action being executed, significantly reducing the attack surface for financial and administrative systems.

When implementing this, failure to enforce server-side validation of the transaction payload against the signature leads to an 'open-loop' vulnerability, where attackers might replay valid signatures for unauthorized transactions.

Operators must verify that the authenticator's public key matches the one stored in the user's registry and ensure the challenge covers the hash of the transaction data, not just an arbitrary nonce. This approach ensures non-repudiation and mitigates risks inherent in standard session management.

Why it matters for identity teams

Identity teams grapple with the limitations of session-based authorization because sessions possess a high blast radius if compromised. Once an attacker extracts an OIDC ID token or a session cookie, they often gain full administrative or transactional access for the duration of that session's validity.

Relying solely on session-based security ignores modern Adversary-in-the-Middle (AitM) techniques that effectively proxy authenticated traffic. By adopting VBA, security teams move beyond passive session trust and force a 'step-up' requirement for dangerous actions. Verify Before Approve is critical when defending against unauthorized wire transfers or privileged role modifications.

The failure mode of traditional identity models is that they assume the person behind the mouse at minute five is the same person who logged in at minute zero.

Teams must implement granular controls to detect when the session context drifts or when the request type shifts into a high-risk category. Using identity security assessment (see Identity Security Assessment). Teams can identify these high-value endpoints and apply VBA systematically rather than globally.

This operational shift effectively breaks the assumption that all traffic from an authenticated session is legitimate.

How it works: The core mechanics

The mechanics of Verify Before Approve depend on decoupling the user's identity from the specific authorization of a transaction.

While traditional IAM frameworks treat 'authentication' as a single gate at the start of a flow, the VBA model treats each significant action as an independent assertion that requires distinct cryptographic proof.

Verify Before Approve separation requires the application to present a clear, signed payload to the authentication device rather than simply prompting for a password or generic push notification. By requiring the user to explicitly verify the data they are approving, you minimize the risk of malicious transaction injection (high-value transaction security).

Separation of authentication and transaction intent

Authentication verifies that the user is who they claim to be, while transactional intent verifies the user agrees to the specific data being presented in the current action. In many legacy systems, an admin logs in and stays authenticated for eight hours.

During this window, any API call made is treated as authorized. VBA breaks this coupling. Even if the admin is authenticated, the system flags specific endpoints, such as /api/v1/transfer or /api/v1/rotate-keys, as requiring a separate intent verification.

To the user's authenticator. If an attacker manages to compromise the session token, they can still access read-only data, but they cannot forge the intent signature required for the write-heavy operations.

The operational failure mode here is a 'missing state-check,' where the backend verifies that a token exists but fails to check if the specific transaction intent was signed within the required TTL (cryptographic proof of intent).

Cryptographic binding and non-repudiation

Cryptographic binding ensures that the signature produced by the FIDO2 device is mathematically linked to the specific request body. When the user initiates a transaction, the server generates a challenge containing a hash of the transaction details (the 'clientDataJSON' and the transaction payload).

The authenticator signs this hash using the private key stored within its secure enclave. If an attacker attempts to modify the transaction parameters, such as swapping a transfer amount, the hash calculated by the authenticator will not match the hash expected by the server, causing the verification to fail.

Verify Before Approve provides strong non-repudiation, as the user has cryptographically committed to the exact data presented in the request.

Without this binding, it is possible for a malicious client-side script to perform a 'man-in-the-browser' attack, where the UI shows one value to the user while the API call sends another to the backend.

Using techniques described in JWT ensures that the claims within these tokens are strictly validated to prevent unauthorized field manipulation (FIDO2 transaction confirmation).

Implementation flow with OIDC and FIDO2

Implementing VBA requires integrating FIDO2's WebAuthn API with your existing OIDC flow. When a user triggers a high-value transaction, the application must issue a new authentication request to the Identity Provider (IdP) with an acr_values parameter requesting 'transactional_verification'. The IdP then sends a challenge to the user's FIDO2 device.

Get()` call should include the SHA-256 hash of the transaction details. Upon receiving the signed response, the IdP or the application backend validates the signature against the user's registered public key. If the signature matches the transaction hash, the action proceeds.

One common failure mode occurs when the IdP fails to enforce the userVerification flag set to required, falling back to insecure methods. You must also monitor for 'sidecar mount' issues where secrets managers in containers fail to provide the correct signing keys to the verification service.

For further security, see Threat Detection to understand how to monitor for repeated failed verification attempts that signal an active attack (identity security patterns).

Common use cases for VBA

Common use cases and scenarios for Verify Before Approve include a named tenant example operators can copy. Verify Before Approve serves as a critical control for any operation where the cost of unauthorized execution outweighs the convenience of a frictionless user experience.

For financial services, this is the primary mechanism for authorizing large-value wire transfers or external account linkage. In cloud infrastructure, it applies to administrative actions like deleting a production database, rotating root access keys, or modifying security group rules that expose services to the public internet.

Administrative portals also benefit from this pattern by requiring a transaction signature before applying changes to global user roles or permission sets.

Verify Before Approve prevents a compromised 'Global Admin' account from wreaking havoc, as the attacker would still need the physical hardware key of the admin to sign off on destructive configuration changes. By enforcing this check, organizations create a reliable 'break-glass' and 'safe-mode' barrier that protects critical resources from lateral movement.

Teams often overlook the necessity of applying this to internal microservices, but implementing VBA between internal service-to-service communication, perhaps (see Hashing). Adds a vital layer of defense-in-depth against credential theft.

Related topics and next reads

FAQ

What is the difference between standard MFA and Verify Before Approve?

Standard MFA verifies that the user is the owner of the account at the beginning of a session. Verify Before Approve (VBA) verifies that the user intends to perform a specific, high-risk action within that session. MFA is an entry gate, while VBA is a persistent guardrail for specific critical operations.

How does FIDO2 enable Verify Before Approve?

FIDO2 supports a 'transaction confirmation' capability where the authenticator displays or allows the device to process transaction data. By including a hash of the transaction in the WebAuthn challenge, the FIDO2 device generates a signature that is mathematically bound to that specific transaction, which the server then validates.

Can Verify Before Approve be implemented with Auth0 or Okta?

Yes, both platforms support OIDC and FIDO2 integration. You implement VBA by requesting a step-up authentication flow using acr_values for high-value endpoints and ensuring your application logic validates that the authentication assertion includes the necessary cryptographic proof of transaction intent.

What defines a 'high-value transaction' for VBA?

High-value transactions include any action that could cause significant financial loss, data breach, or loss of system control. Examples include wire transfers, modification of security policies, rotation of root secrets, or the deletion of production databases.

How does VBA solve the problem of session hijacking?

In a session-hijacking scenario, an attacker gains control of a user's browser session. While they can perform standard tasks, they cannot forge the cryptographically bound signature required by VBA because they lack access to the physical security key that holds the private key for signing transaction intents.