Struct TokenManager 

pub struct TokenManager { /* private fields */ }

Implementations

impl TokenManager

pub fn new(secret: &[u8], issuer: Option<String>) -> Self

Creates a TokenManager for symmetric signing (HS256).

pub fn new_asymmetric( private_key_pem: &[u8], issuer: Option<String>, kid: Option<String>, ) -> Result<Self, AuthError>

Creates a TokenManager for asymmetric signing (RS256). private_key_pem must be a valid RSA private key in PEM format. OP/external verification should use this path; internal resource servers can continue to use new (HS256).

pub fn public_jwk(&self) -> Option<Jwk>

pub fn with_issuer(self, issuer: String) -> Self

pub fn issue_user_token( &self, identity: Identity, expires_in_secs: u64, scope: Option<String>, aud: Option<String>, ) -> Result<String, AuthError>

Issues a token for a user identity.

pub fn issue_user_token_with_extra( &self, identity: Identity, expires_in_secs: u64, scope: Option<String>, aud: Option<String>, extra: HashMap<String, Value>, ) -> Result<String, AuthError>

Issues a token for a user identity, stamping the given extra claims onto the token in addition to the standard/core claims.

This lets a host application (e.g. a resource server built on top of this engine) attach domain-specific claims — such as api_key_id, project_id, or roles — so downstream consumers (an API gateway or authorization proxy) can read them directly off the token without a database round-trip. Keys in extra take precedence over any same-named field set elsewhere in extra by this method; they cannot override the top-level standard claims (sub, aud, exp, etc.) since those are not part of the flattened map.

pub fn issue_id_token( &self, identity: Identity, client_id: &str, nonce: Option<String>, expires_in_secs: u64, ) -> Result<String, AuthError>

Issues an OIDC-conformant ID token.

pub fn issue_id_token_with_extra( &self, identity: Identity, client_id: &str, nonce: Option<String>, expires_in_secs: u64, extra: HashMap<String, Value>, ) -> Result<String, AuthError>

Issues an OIDC-conformant ID token, stamping the given extra claims onto the token in addition to the standard/core claims.

nonce is a reserved claim key: extra is merged into the token first, then the explicit nonce parameter is applied on top. So if nonce is Some(_), it always wins over any "nonce" entry passed in extra. If nonce is None, an extra["nonce"] value (if any) is left as-is. This preserves OIDC nonce semantics — it reflects what the client sent in the authorization request — and keeps it from being accidentally clobbered by unrelated custom claims.

pub fn issue_client_token( &self, client_id: &str, expires_in_secs: u64, scope: Option<String>, aud: Option<String>, ) -> Result<String, AuthError>

Issues a machine-to-machine (M2M) token for a client.

pub fn issue_client_token_with_extra( &self, client_id: &str, expires_in_secs: u64, scope: Option<String>, aud: Option<String>, extra: HashMap<String, Value>, ) -> Result<String, AuthError>

Issues a machine-to-machine (M2M) token for a client, stamping the given extra claims onto the token in addition to the standard/core claims. See Self::issue_user_token_with_extra for the rationale.

pub fn issue_custom_token( &self, sub: String, expires_in_secs: u64, typ: &str, extra: HashMap<String, Value>, ) -> Result<String, AuthError>

Issues a token with an explicit typ header and no aud, for callers minting something that is not a standard OIDC ID/access/user token and needs its own wire-format typ so verifiers can tell it apart from those (e.g. authkestra-op’s device/service attestations, whose contract requires typ: "webank-attest+jws" rather than the default "JWT"). Additive alongside the issue_*_token* family above; those are unchanged.

pub fn validate_token( &self, token: &str, expected_aud: Option<&str>, ) -> Result<Claims, AuthError>

Trait Implementations

impl Clone for TokenManager

fn clone(&self) -> TokenManager

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.