Struct AuthplaneResource

Source

pub struct AuthplaneResource { /* private fields */ }

Implementations§

Source §

impl AuthplaneResource

Source

pub async fn create( issuer: &str, resource: &str, scopes: &[String], fetch_settings: FetchSettings, ) -> Result<Self, VerifierError>

Source

pub async fn create_with_options( issuer: &str, resource: &str, scopes: &[String], fetch_settings: FetchSettings, options: ResourceOptions, ) -> Result<Self, VerifierError>

Source

pub fn prm_document_url(&self) -> Result<String, AuthplaneError>

RFC 9728 §3.1 — absolute URL of this resource’s metadata document, derived from the resource identifier. This is where a server that hosts its own document should serve it.

Source

pub fn resource_metadata_url(&self) -> &str

The URL advertised as the RFC 9728 §5.1 resource_metadata parameter of every WWW-Authenticate challenge this resource emits: the ResourceOptions::with_resource_metadata_url override when set, otherwise Self::prm_document_url.

Source

pub fn www_authenticate(&self, error: &VerifierError, realm: &str) -> String

Build the WWW-Authenticate challenge for a verifier failure on this resource: www_authenticate() plus the RFC 9728 §5.1 resource_metadata parameter carrying Self::resource_metadata_url. Adapters should prefer this over the free function so every 401 tells the client where to discover the authorization server. realm is optional; pass "" to omit it.

Source

pub async fn verify(&self, token: &str) -> Result<VerifiedClaims, VerifierError>

Verify a bearer access token (RFC 6750 §2.1).

Rejects a DPoP-bound token rather than accepting it as a bearer one. A cnf claim means the authorization server issued this token sender-constrained, and the binding is the whole reason a stolen token is useless to a thief. This entrypoint has no request context, so it has no proof to check against — accepting the token anyway would silently discard the constraint, which is a downgrade, not a limitation.

Token without cnf: verified and returned.
Token with cnf, resource not configured for inbound DPoP (Mode 3): VerifierError::DpopNotSupported — the same answer verify_with_context gives.
Token with cnf, resource is configured for inbound DPoP (Modes 1 and 2): VerifierError::DpopBindingMismatch — a proof is required and this entrypoint cannot supply one. Use verify_with_context.

Mode dispatch comes first, so a malformed cnf cannot select a weaker path than a well-formed one. It is not separated out beyond that: verify_with_context checks for cnf.jkt before the proof-missing check and answers VerifierError::InvalidClaims for a cnf without one, which this entrypoint does not reproduce — there is no proof to bind either way here, so the malformed case folds into the same rejection. Both reject; the class differs, and the catalog case that pins invalid_claims for that shape (rfc9449-dpop-bound-token-must-contain-cnf-jkt) is specified against the DPoP entrypoint with a proof present, not against this one.

Source

pub async fn verify_with_context( &self, token: &str, context: &DpopRequestContext, ) -> Result<VerifiedClaims, VerifierError>

RFC 9449 §7 — unified verify entrypoint.

Accepts both bearer and DPoP-bound access tokens behind a single API that takes a request-level DpopRequestContext and uses the token’s cnf.jkt claim to decide whether sender-constraint validation must run, so a caller need not decide up front which entrypoint a token requires.

Behavior matrix:

Token without cnf/cnf.jkt: ignored request context; verification succeeds as a bearer token.
Token with cnf but no cnf.jkt: rejected with VerifierError::InvalidClaims — structurally malformed confirmation claim.
Token with cnf.jkt and context.proof == None: rejected with VerifierError::DpopProofMissing.
Token with cnf.jkt and context.proof = Some(_): proof is validated (method, URL, nonce, ath, and cnf.jkt ↔ jwk thumbprint binding). Mismatch surfaces as VerifierError::InvalidClaims.