Account recovery
The account recovery journey (journey ID account_recovery) helps users who can no longer sign in: they forgot their password, lost their phone or their passkey is gone. Recovery restores access to a sign-in method, not only to a password. Many users have no password at all.
Recovery is a sensitive journey: whoever completes it controls the account. You decide how a user proves who they are. You can use the proofs that cidaas provides, your own identification checks, or a combination of both. A simple password reset by code or link is one possible design among several.
How account recovery works
The orange boxes are the injection points where you can add custom tasks. In step 2 you configure which proofs the journey uses: only your own checks, only a proof provided by cidaas, or both one after the other.
Design your recovery journey
The following patterns show the range. They can be combined.
| Pattern | How the user proves identity | Typical for |
|---|---|---|
| Password reset | Code or link to the verified email address or mobile number, then a new password | Consumer services with password sign-in and a low risk per account |
| Proof provided by cidaas | A verification method, identity verification or a trusted device (see below) | Accounts without a password, higher assurance |
| Your own identification | Your tasks check data from your master data or other information that matters in your business, for example customer number and date of birth, contract or meter number, or a check by your own service desk | Customers who already know their users well, B2B, utilities, insurance |
| Combination | Your own identification first, then a proof provided by cidaas, or the other way round | Banks and other regulated services |
Proofs provided by cidaas
| Proof | How it works | Notes |
|---|---|---|
| Verification method | A code or link to a verified email address or mobile number, or another method the user has enrolled | The methods allowed for recovery are set in the verification options |
| Identity verification | The user proves their identity again with the EUDI Wallet or the cidaas ID Validator (document and liveness check) | The confirmed attributes must match the account |
| Trusted device | The user approves the recovery on a device that is still signed in, for example your mobile app with a cidaas authenticator. The new device takes over the authenticated user. | The approving device must hold a bound sign-in method. A device that is merely known is not enough. |
Your own identification
You add your own identification as custom tasks:
- Automated — a Web API of yours checks the entered identifier or further data against your master data and answers with match or no match.
- Interactive — a custom page asks for information only the real customer knows, for example a customer number, a contract number or the date of birth, and your Web API checks it.
Your task writes its result to your own context variables, for example c_personMatch. If the check fails, your task ends the journey.
Who decides what is sufficient
You define in the journey which proofs lead to which restore action. Keep in mind:
- The proof should match the restore action. A code to the email address may be enough for a new password. Replacing all sign-in methods or binding a new device usually needs a stronger proof.
- Your own checks are your responsibility. If you restore access based on your own identification only, the security of the recovery depends on the quality of your data and checks. Data that others can find out easily, such as name and address, is not a proof.
- Account existence. Before the identity is proven, do not reveal whether an account exists. A message such as “You are not a customer” tells the user whether a customer record exists.
Injection points
| Injection point | Position | Allowed tasks | Typical use |
|---|---|---|---|
after_recovery_identification | after the user entered the identifier, before any proof | automated, interactive | Your own identification: pre-check in your master data, or ask for and check your own identification data |
after_recovery_proof | after the proof, before access is restored | automated, interactive | Master data match: do the confirmed attributes match your record? Ask for an additional proof such as a contract number. |
after_recovery_complete | after access is restored | automated | Inform your systems, for example as a security event |
Rules:
- At
after_recovery_identificationthe identifier is not proven. If the person is not found, end the journey and do not reveal more than the user entered. - If your check does not find the person, the journey ends. You decide which message the user sees.
Context variables
| Variable | Type | Meaning | Write |
|---|---|---|---|
client_id | string | Application that started the recovery | no |
recoveryIntent | string | Reason stated by the user: forgotten, lost, stolen, compromised, locked, unavailable. Not verified. | no |
identifier | string | Identifier the user entered. Personal data. Not proven before the proof. | no |
identifierType | string | Kind of identifier, e.g. email or mobile number | no |
recoveryProof.method | string | Method that produced a proof provided by cidaas, e.g. EUDI_WALLET | no |
recoveryProof.verifiedAttributes | object | Attributes confirmed by identity verification, e.g. name and date of birth. Personal data. | no |
sub | string | User ID, available after the proof | no |
restoreAction | string | Restore action performed, e.g. new passkey or new password | no |
c_* | any | Your own variables, e.g. c_masterDataFound, c_personMatch | yes |
Examples
Example 1: Password reset
An online shop lets users sign in with email and password. Recovery is a code to the verified email address, then a new password. No custom tasks are needed. Optionally, a task at after_recovery_complete informs the shop system.
Example 2: Identification with your own customer data
An energy supplier knows its customers by customer number and meter number. Many users have no verified mobile number.
| Injection point | Task | Configuration |
|---|---|---|
after_recovery_identification | interactive, custom page c_customer_identification | Asks for customer number, meter number and date of birth. Writes c_customerNumber, c_meterNumber, c_birthdate. |
after_recovery_identification | automated, Web API crm-identify-customer | Input: identifier, c_customerNumber, c_meterNumber, c_birthdate. Output: c_personMatch. Condition ctx.c_personMatch == false ends the journey with a neutral message. |
after_recovery_complete | automated, Web API crm-recovery-event | Input: sub, restoreAction. Records the recovery in the CRM. |
The supplier uses its own identification as the proof and allows a new password or a new passkey after a successful match.
Example 3: Identity verification and master data check
A bank allows recovery by identity verification and wants to make sure the person is still a customer.
| Injection point | Task | Configuration |
|---|---|---|
after_recovery_identification | automated, Web API core-customer-exists | Input: identifier. Output: c_masterDataFound. Condition ctx.c_masterDataFound == false ends the journey without further information. |
after_recovery_proof | automated, Web API core-match-person | Input: recoveryProof.verifiedAttributes, sub. Output: c_personMatch. No match ends the journey with the bank's message. |
after_recovery_complete | automated, Web API siem-recovery-event | Input: sub, restoreAction. Reports the recovery to the security monitoring. |
Next steps
- Custom tasks: register your Web APIs and custom pages
- Journey model: conditions and input and output mapping
Please contact us directly on our support page or reach out to cidaas support at [email protected].