Your verification link is single-use. That does not prove who opened it.
Charles Archibong, Co-founder
A single-use link limits reuse; it does not by itself establish who redeemed it. Bind each verification journey to the intended customer on your server and check that binding before granting account access.
Key takeaways
- Possession of a link and ownership of an account are different evidence.
- Create and retain the customer-to-session binding on your backend.
- Use the authoritative result and binding before changing account permissions.
A completed verification belongs to the customer and journey your server created. Before changing an account's permissions, check that relationship against the authoritative result. A successful browser return or possession of a single-use link is not enough.
Consider an illustrative support journey: an agent copies a verification URL into the wrong conversation. Even if it can only be used once, you still need to know which account the resulting evidence is allowed to affect.
Create the binding before sending the link
Create the journey from your backend using the intended customer reference, organisation, environment and workflow. Save the returned session reference against that application before delivering the URL.
Do not let a browser-supplied customer ID choose whose account becomes verified. Check that the requesting user is allowed to start the journey for that account.
OWASP's authorisation guidance (opens in a new tab) recommends checking permissions on every request. Apply that principle when creating a journey and when consuming its result.
Treat delivery as part of the control
Send the link through the intended customer channel. Keep full verification URLs out of analytics events, screenshots and support notes that do not need them. Use references rather than copying the URL between teams.
If a link reaches the wrong person, use the provider's documented revocation or expiry controls where supported. Do not assume creating another link disables the first. Escalate when you cannot establish the remaining exposure.
OWASP's session guidance (opens in a new tab) explains why tokens carried in URLs need careful handling. Confirm your provider's actual session behaviour rather than inventing guarantees.
Accept the result on your server
When the result arrives, verify its authenticity and retrieve current state where needed. Match it to your stored customer, journey and environment. Check the final decision required by your policy before granting permissions.
A capture-complete screen can tell the customer what happens next. It should not independently approve their account. Keep pending, reviewed and completed states meaningful.
Test the wrong-recipient path
Test two customers in separate browser sessions, a link opened by the unintended recipient, an expired journey and a delayed result. Confirm that no result can update an unrelated account.
Toden supports customer-bound hosted journeys; your application still enforces the account permissions. Start with the hosted-versus-SDK guide, then use the integration references to verify the binding end to end.
Sources
Charles Archibong
Co-founder
Charles Archibong co-founded Toden. He writes about identity verification, financial technology, and the practical work of building trusted digital services.
