pub struct Client {
pub client_id: ClientId,
pub auth: ClientAuth,
pub grant_types: Vec<GrantType>,
pub redirect_uris: Vec<String>,
pub allowed_scopes: ScopeSet,
pub default_scopes: ScopeSet,
pub name: Option<String>,
pub registration: Option<Box<DynamicRegistration>>,
}Expand description
A registered client: identity, authentication, and what it is allowed to do.
Fields§
§client_id: ClientIdThe unique client identifier.
auth: ClientAuthHow the client authenticates.
grant_types: Vec<GrantType>The grant types this registration may use; anything else is unauthorized_client.
redirect_uris: Vec<String>Registered redirect URIs (authorization-code grant; exact-match per OAuth 2.1).
allowed_scopes: ScopeSetThe scopes this client may ever be granted; a request outside this set is invalid_scope.
default_scopes: ScopeSetThe scopes granted when a request names none (RFC 6749 section 3.3 server default).
name: Option<String>Human-readable name for consent and admin surfaces.
registration: Option<Box<DynamicRegistration>>Present exactly when this registration was created by RFC 7591 dynamic client registration, and absent for one the host provisioned itself.
BOXED, and this is not a style choice, though the reason is no longer the one it was
written for. The original argument was that a Client is deep cloned out of the store on
every token-plane request, so every byte here is paid per request;
crate::store::Storage::get_client hands back an Arc<Client> now, so a read is a
pointer clone and the struct’s SIZE is not on that path at all.
Re-examined on that basis, the box is MORE clearly right than when it was chosen, because
the optimisation removed its only cost. What it buys is now a memory argument rather than a
per-request one. MEASURED: Option<Box<DynamicRegistration>> is 8 bytes against 104 for
the record inline, which is the difference between a Client of 200 bytes and one of 296,
paid by every registration in every store whether or not RFC 7591 is enabled. What it USED
to cost was an extra allocation on every clone of a client that does have one; with Arc
there are no such clones, so that allocation is now paid exactly once, when the
registration is created.
It lives on the client rather than in a table of its own because it IS the client: RFC 7592 section 2 manages a registration through the same identifier the token endpoint authenticates, and splitting the two across two stores would make deletion a two-phase problem the host has to get right.