Enum ClientAuth 

#[non_exhaustive]
pub enum ClientAuth {
    Public,
    ConfidentialSecret {
        secret: String,
    },
    ConfidentialSecretHash {
        hash: SecretHash,
    },
    ConfidentialAssertion {
        keys: AssertionKeys,
    },
    Mtls {
        registration: MtlsClientRegistration,
    },
}

How the client authenticates to the token endpoint (RFC 6749 section 2.3).

Debug is hand-written rather than derived (see below) so that ConfidentialSecret’s secret never appears in a debug format. Client derives Debug and holds a ClientAuth, so this also keeps {:?} on a whole Client safe, without needing a hand-written Debug there too. #[non_exhaustive]: client-assertion and mtls each add a variant, independently, so this enum has four possible variant sets. A host matches this to render “how does this client authenticate” in an admin UI, or to decide what its own registration endpoint will accept, and neither of those should stop compiling because an unrelated crate in the graph wanted mutual TLS. Registering a client is unaffected: naming a variant is still just naming it.

Variants (Non-exhaustive)

Non-exhaustive enums could have additional variants added in future. Therefore, when matching against variants of non-exhaustive enums, an extra wildcard arm must be added to account for any future variants.

Public

A public client (native app, browser app, device): no secret exists, so possession of the client_id proves nothing and the flows compensate (PKCE, device-code user interaction).

ConfidentialSecret

A confidential client whose SECRET ITSELF is stored here.

PREFER ClientAuth::ConfidentialSecretHash. This variant means the plaintext credential lives wherever the host persists a Client, so a leak of that store is a leak of every client’s working credential, and the host cannot honestly tell a customer that their secret is not recoverable. It stays supported because it is legitimately right for two cases: a host that resolves secrets from a vault or KMS at request time and never writes them down, and a host migrating registrations gradually. This crate only ever compares it, in constant time, and never logs it.

Fields

secret: String

The shared secret the client presents.

ConfidentialSecretHash

A confidential client stored as a one-way VERIFIER rather than as its secret. This is the variant to reach for: see SecretHash.

Fields

hash: SecretHash

The stored verifier.

ConfidentialAssertion

Available on crate feature client-assertion only.

A confidential client that authenticates with an RFC 7523 signed assertion rather than by presenting a secret: private_key_jwt or client_secret_jwt.

The keys are held INLINE rather than behind a Box, unlike Client::registration. The question is what this costs a deployment that does not use it, and the answer is nothing: the widest existing variant is ConfidentialSecretHash (two Strings), and crate::client_assertion::AssertionKeys is narrower than that, so ClientAuth does not grow by a byte. Boxing would have ADDED an allocation at registration time to save a struct size that was already paid for.

Fields

keys: AssertionKeys

What the registration expects the assertion to be signed with. This, and never the token’s own header, is what decides the algorithm: see crate::client_assertion::verify_assertion.

Mtls

Available on crate feature mtls only.

RFC 8705: a confidential client that authenticates with a mutual-TLS CERTIFICATE and holds no shared secret at all. This is the variant a deployment whose policy forbids shared secrets registers, and the only one where the credential never travels: the client proves possession of a private key to the host’s TLS layer, and this crate is handed the resulting certificate as an established fact.

Carried INLINE rather than boxed, on the same measurement as the assertion variant above: the widest shape crate::mtls::MtlsClientRegistration can take is one String plus a discriminant, against ConfidentialSecretHash’s two Strings, so this variant does not make ClientAuth, or the Client every host store holds one of per registration, any bigger than it already was.

Fields

registration: MtlsClientRegistration

Which RFC 8705 method, and what it expects to see.

Implementations

impl ClientAuth

pub fn is_confidential(&self) -> bool

Whether this registration is CONFIDENTIAL, meaning the client can prove possession of something. RFC 6749 section 4.4 (client credentials), RFC 7662 section 2.1 (introspection) and RFC 7009 section 2.1 (revocation) all require that, and the answer must not be “is this variant ConfidentialSecret”, because a new storage form for the same credential would then silently read as public.

pub fn verify(&self, presented: Option<&str>) -> bool

Verify a presented secret with no host verifier installed. See ClientAuth::verify_with, which this delegates to; a ClientAuth::ConfidentialSecretHash in a scheme this crate does not implement therefore never authenticates through this entry point.

pub fn verify_with( &self, presented: Option<&str>, verifier: Option<&dyn SecretVerifier>, ) -> bool

Verify a presented secret, consulting the host’s SecretVerifier for hash schemes this crate does not implement.

Public clients accept None and reject any presented secret (presenting a secret for a secretless registration is a client mixup worth failing loud on). Confidential clients require the exact secret; the comparison is constant time regardless of the length of either the registered or the presented secret: an early-exit comparison would report, through its own timing, how many leading bytes of a guess were right.

ORDER OF PREFERENCE for a hashed registration: the crate’s own scheme is checked by the crate, and only an unrecognised scheme is passed to verifier. That way installing a verifier can only ADD registrations that authenticate, never change the answer for one the crate could already decide.

What this does NOT cover, and who does: if the caller returned early for an unknown client_id without calling this at all, an unknown client and a known client with a wrong secret would be distinguishable by timing even though this function leaks nothing. That is the caller’s responsibility rather than this function’s, and AuthorizationServer::authenticate_client discharges it by running a DUMMY verification through this same function on the unknown-id path. See SecretVerifier::dummy_hash for the part of it only the host can supply.

Trait Implementations

impl Clone for ClientAuth

fn clone(&self) -> ClientAuth

Returns a duplicate of the value.

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

Performs copy-assignment from source.

impl Debug for ClientAuth

Hand-written so ConfidentialSecret { secret } never prints the secret. An AS library that logs nothing itself should still not make tracing::debug!(?client) on a host’s part into a plaintext credential leak; deriving Debug here would do exactly that. Every non-secret variant and field stays visible so the type is still useful to debug-print.

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl<'de> Deserialize<'de> for ClientAuth

fn deserialize<__D>(__deserializer: __D) -> Result<Self, __D::Error>

where __D: Deserializer<'de>,

Deserialize this value from the given Serde deserializer.

impl Eq for ClientAuth

impl PartialEq for ClientAuth

fn eq(&self, other: &ClientAuth) -> bool

Equality operator ==.

fn ne(&self, other: &Rhs) -> bool

Inequality operator !=.

impl Serialize for ClientAuth

fn serialize<__S>(&self, __serializer: __S) -> Result<__S::Ok, __S::Error>

where __S: Serializer,

Serialize this value into the given Serde serializer.

impl StructuralPartialEq for ClientAuth