Struct ResourceServerRegistration 

#[non_exhaustive]
pub struct ResourceServerRegistration {
    pub client_id: ClientId,
    pub resources: Vec<String>,
}

One resource server, as ServerConfig::resource_servers declares it: the registered client identity it authenticates as, and the RFC 8707 resource identifiers it is the protected resource FOR.

The two halves answer two different questions and neither substitutes for the other. client_id answers “who is calling”, and it is checked by the ordinary client authentication every endpoint uses, so a resource server needs a real credential and gets constant-time verification, rotation and revocation for free. resources answers “what may it ask about”, and it is checked against the token’s own crate::IssuedToken::resource set, so a resource server is told about tokens addressed to it and is told {"active": false} about every other token in the store.

Registering the same client_id twice is not an error and not special: the identifier sets are considered in order and a match in any of them is a match. It is simply a longer way of writing one entry with both lists concatenated. #[non_exhaustive]: this is a DEPLOYMENT POLICY object for a channel that will grow. A per-RS claim filter, a per-RS introspection policy and a token_endpoint_auth_method constraint are all plausible next fields, and each one would be a major-version event if a host could write a struct literal here. Its sibling crate::cimd::CimdPolicy is sealed for the same reason and states it plainly: “A host writes a full struct literal today and has a build that breaks on a patch release; new() plus assignment does not. The attribute cannot be added after publication, because by then the literal is in somebody’s production tree.”

It is sealed HERE rather than later because 0.9.2 is the release that introduces it. The tests/host_api_shape.rs gate does not catch this one and is not wrong to miss it – that scan flags types whose field set VARIES WITH A CARGO FEATURE, and this one’s does not. The rule the crate actually follows is broader than the gate that enforces part of it.

Fields (Non-exhaustive)

Non-exhaustive structs could have additional fields added in future. Therefore, non-exhaustive structs cannot be constructed in external crates using the traditional Struct { .. } syntax; cannot be matched against without a wildcard ..; and struct update syntax will not work.

client_id: ClientId

The registered client this resource server authenticates as. It must be a CONFIDENTIAL client: introspection refuses public clients (see AuthorizationServer::introspection_response_with_credential), and naming a public client here therefore registers a resource server that can never successfully call.

resources: Vec<String>

The RFC 8707 resource identifiers this server is the protected resource for. An entry with an EMPTY list can never match any token, because matching requires naming an identifier the token carries; it registers a resource server with no authority rather than one with universal authority, which is the fail-closed direction.

Implementations

impl ResourceServerRegistration

pub fn new( client_id: ClientId, resources: impl IntoIterator<Item = impl Into<String>>, ) -> Self

Declare client_id to be the resource server for resources.

Trait Implementations

impl Clone for ResourceServerRegistration

fn clone(&self) -> ResourceServerRegistration

Returns a duplicate of the value.

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

Performs copy-assignment from source.

impl Debug for ResourceServerRegistration

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

Formats the value using the given formatter.

impl Eq for ResourceServerRegistration

impl PartialEq for ResourceServerRegistration

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

Equality operator ==.

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

Inequality operator !=.

impl StructuralPartialEq for ResourceServerRegistration