Ask for fresh proof before a sensitive action
A person can stay signed in for everyday work and still prove their identity again before a high-impact action. Wildo connects the operation’s requirement to a fresh authentication challenge and resumes the action after verification.
You select the operations and accepted proof methods. The extra check complements their access rules; it does not grant a role the person lacks.
Example — Confirm who is deleting an account
An administrator can browse account settings normally. Deleting an account requires fresh proof before the operation proceeds.
For engineers
Put the requirement on the operation
The engine’s user-deletion API variant declares both who may call it and the additional proof it requires. Selected fields from users.shared.resources-config.schemas.ts:
variantType: ResourceOperationVariantType.API_CALL,
isDefault: true,
roles: [CORE_APP_ROLES.APP_ADMIN_SUPER_ADMIN],
admitsCrossSubjectUserAdministration: true,
riskLevel: ResourceOperationRiskLevel.CRITICAL,
requiresStepUpAuthentication: true,
riskLevel controls how danger is presented; it is not the reauthentication gate. requiresStepUpAuthentication is the explicit requirement. The role gate remains in force.
Exchange a fresh factor for an operation proof
The reauthentication service accepts password, an enrolled TOTP or recovery code, or a passkey assertion. Passkey step-up uses its own challenge and requires user verification, so a normal login assertion cannot be replayed as step-up.
After verifying the factor, AuthMethodManagementBackendService produces this proof:
const token = await this.consumableTokenService.createToken({
tokenType: CoreConsumableTokenTypes.REAUTH,
consumptionMode: ConsumableToken_ConsumptionMode.SINGLE_USE,
expiresIn: { value: 5, unit: DurationUnit.MINUTES },
userId: userId,
resourceIdentifier: CoreResourceType.USERS,
relatedId: userId,
});
return { reAuthToken: token.token };
The standard frontend’s StepUpAuthContext coordinates the challenge and pending action. The backend operation gate consumes the proof for the authenticated person; a custom interface needs the same continuation rather than treating the challenge as an independent login screen.
Keep policy and enrolled methods compatible
When the effective stepUpAuth policy is enabled, its methods constrains which factors may mint the proof. The resolver includes the actual subject’s organization memberships, so organization restrictions participate rather than reading only the raw user-type policy.
An operation’s explicit requiresStepUpAuthentication can require proof even when the policy-level switch is disabled; in that case the enabled-policy method restriction does not apply. The resource-operation gate covers direct user requests, with exemptions for worker execution, nested service calls and its declared read-operation set.
A person must have a factor the minting path accepts enrolled locally; an SSO identity alone is not a password, TOTP or passkey proof. A proof already minted remains usable until its short expiry even if the accepted-method policy changes in the meantime.