Struct ChallengeStore

Source

pub struct ChallengeStore { /* private fields */ }

Expand description

In-memory store of pending WebAuthn challenges with single-use consumption and expiry enforcement.

Construct with ChallengeStore::new or ChallengeStore::with_clock (the latter for deterministic expiry tests). See the module documentation for the threat model and storage contract.

§Requirements

REQ-WA-108, REQ-WA-109, REQ-WA-115, REQ-WA-200

Implementations§

Source §

impl ChallengeStore

Source

pub fn new() -> Self

Create a new empty challenge store using the system clock.

Source

pub fn with_clock(now: Arc<dyn Fn() -> i64 + Send + Sync>) -> Self

Create a challenge store with an injectable clock (Unix seconds), primarily for deterministic expiry testing.

Source

pub fn store_registration_challenge( &mut self, challenge_id: &str, username: &str, challenge_bytes: Vec<u8>, )

Store a pending registration challenge.

The challenge is keyed by challenge_id (an opaque handle the caller tracks in its own session state) and stores the raw challenge bytes the client must echo back.

Source

pub fn store_registration_challenge_at( &mut self, challenge_id: &str, username: &str, challenge_bytes: Vec<u8>, created_at: i64, )

Store a pending registration challenge with an explicit creation timestamp (Unix seconds). Useful for testing expiry and for restoring persisted state.

Source

pub fn consume_registration_challenge( &mut self, challenge_id: &str, timeout_secs: u64, ) -> Result<(String, Vec<u8>), WebauthnError>

Consume a registration challenge (single use), returning the associated username and raw challenge bytes.

§Security notes

The entry is removed before validation results are returned, so a challenge can never be used twice (replay protection).
Expired challenges are rejected with WebauthnError::ChallengeExpired.
Unknown IDs are rejected with WebauthnError::InvalidChallenge.

§Requirements

REQ-WA-108, REQ-WA-109

Source

pub fn store_authentication_challenge( &mut self, challenge_id: &str, username: &str, challenge_bytes: Vec<u8>, allowed_credential_ids: Vec<String>, )

Store a pending authentication challenge.

Source

pub fn store_authentication_challenge_at( &mut self, challenge_id: &str, username: &str, challenge_bytes: Vec<u8>, allowed_credential_ids: Vec<String>, created_at: i64, )

Store a pending authentication challenge with an explicit creation timestamp (Unix seconds).

Source

pub fn consume_authentication_challenge( &mut self, challenge_id: &str, timeout_secs: u64, ) -> Result<(String, Vec<u8>, Vec<String>), WebauthnError>

Consume an authentication challenge (single use), returning the username, raw challenge bytes, and the allowed credential IDs.

Same security semantics as ChallengeStore::consume_registration_challenge.

§Requirements

REQ-WA-108, REQ-WA-109

Source

pub fn generate_registration_challenge( &self, config: &WebauthnConfig, username: &str, display_name: &str, existing_credential_ids: &[String], ) -> (String, RegistrationOptions)

Generate a fresh registration challenge and the corresponding navigator.credentials.create() options.

The advertised pubKeyCredParams are built from WebauthnConfig::allowed_algorithms; unknown algorithm IDs are skipped (advertised as “unknown” device names by the protocol layer is not a concern here). existing_credential_ids are advertised as excludeCredentials so compliant authenticators refuse re-registering a credential the server already holds.

The residentKey / userVerification / attestation preferences in the options reflect the corresponding WebauthnConfig settings; when ResidentKeyPolicy::Required is configured, the L2 requireResidentKey = true flag is emitted as well. These are preferences: server-side enforcement lives in crate::policy::CredentialPolicy.

Returns (challenge_id, options); the challenge ID doubles as the Base64url challenge string and the returned options embed the same value. Store the pair via ChallengeStore::store_registration_challenge.