Struct AsyncVerifier 

pub struct AsyncVerifier { /* private fields */ }

Async verifier with JWKS caching support

Implementations

impl AsyncVerifier

pub fn with_static_key( key: VerifyingKey, issuer: impl Into<String>, audience: impl Into<String>, ) -> AsyncVerifier

Create a verifier with a static key

pub fn with_jwks( jwks: Jwks, issuer: impl Into<String>, audience: impl Into<String>, ) -> AsyncVerifier

Create a verifier with JWKS

pub fn with_jwks_url( url: impl Into<String>, issuer: impl Into<String>, audience: impl Into<String>, ) -> AsyncVerifier

Create a verifier that fetches JWKS from a URL

pub fn with_origin_validation(self) -> AsyncVerifier

Require origin validation on verified tokens.

pub fn with_claim_seal_keys(self, keys: ClaimSealKeys) -> AsyncVerifier

Open sealed claims with these keys. Without them, a token that carries sealed claims is refused.

pub fn with_cache_duration(self, duration: Duration) -> AsyncVerifier

Set how long fetched JWKS keys count as fresh. Once they are stale, requests try to refetch them (subject to the minimum refresh interval) and keep verifying against them until a fetch succeeds.

pub fn with_min_refresh_interval(self, interval: Duration) -> AsyncVerifier

Set the minimum time from the end of one JWKS fetch to the start of the next, whatever triggers it: expiry, an unknown kid, or a failed fetch. A key published at the JWKS URL is picked up within about this interval. Defaults to DEFAULT_MIN_JWKS_REFRESH_INTERVAL.

pub async fn verify( &self, token: &str, expected_origin: Option<&str>, expected_client_ip: Option<&str>, ) -> Result<AuthContext, VerifyError>

Verify a token with automatic JWKS fetching and caching

pub async fn refresh_cache(&self) -> Result<(), VerifyError>

Fetch the JWKS from the configured URL now, ignoring the minimum refresh interval. Waits for a fetch already in flight. On failure the previously fetched keys stay in use.

pub async fn verify_with_cache( &self, token: &str, expected_origin: Option<&str>, expected_client_ip: Option<&str>, ) -> Result<AuthContext, VerifyError>

Verify a token against the JWKS fetched from the configured URL.

Fresh keys are used directly. An unknown kid, stale keys, or no keys trigger a refetch, but at most one fetch runs at a time and the next waits out the minimum refresh interval, so tokens with made-up key IDs cannot drive outbound requests. If the fetch fails or is skipped, the last successfully fetched keys are used.