Struct TokenRequestContext 

#[non_exhaustive]
pub struct TokenRequestContext<'a> {
    pub credential: ClientCredential<'a>,
    pub resources: &'a [String],
    pub authorization_details: Option<&'a str>,
    pub dpop_proof: Option<&'a str>,
}

Everything about a token request that is not part of the grant itself.

Passed by reference to AuthorizationServer::token_with_context. Growing this struct is cheap; growing TokenRequest is not, because a host copies that around and tests/allocation.rs holds it to a size budget. #[non_exhaustive]: rar and dpop each add a field, and this is the type a host assembles on EVERY token request, so it is the single most likely struct literal in a host’s codebase and the most expensive one to break. “Growing this struct is cheap” above is only true while growing it is not a semver-major change, which is what the attribute buys.

Build it with TokenRequestContext::new and assign what the request carried; Default is still there for a request with no credential at all, though the credential is the one thing every request has an answer for, which is why it is the constructor’s only argument.

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.

credential: ClientCredential<'a>

How the client is authenticating.

resources: &'a [String]

The RFC 8707 resource parameters, in wire order.

authorization_details: Option<&'a str>

The RFC 9396 authorization_details parameter, raw and unparsed.

Here rather than on each TokenRequest variant for the reason resources is here: section 6 defines it as a parameter of the token REQUEST, independent of grant_type. What it MEANS does depend on the grant, and section 6 is what decides: authorization_code and refresh_token may narrow what the authorization request obtained and never widen it; client_credentials has no prior authorization request, so its details are checked against the supported types and used; and the device grant refuses any at all, because the RFC 8628 section 3.1 request cannot carry them in this crate and so granted nothing for a poll to narrow to.

NOT FEATURE GATED, for the reason crate::authorization::AuthorizationRequest::authorization_details is not: a build without rar still has to be TOLD the parameter arrived, because refusing it is what RFC 9396 section 5 requires of exactly that build. Setting it in such a build makes the request an error rather than making the field meaningless.

dpop_proof: Option<&'a str>

Available on crate feature dpop only.

The RFC 9449 DPoP request header, verbatim and unparsed.

None means the client sent none, which is refused only when ServerConfig::require_dpop is set. When it is present and valid, the issued token is BOUND to the proof’s key: token_type becomes DPoP and RFC 7662 introspection reports cnf.jkt.

Implementations

impl<'a> TokenRequestContext<'a>

pub fn new(credential: ClientCredential<'a>) -> Self

The context of a request that carried nothing but its client authentication, which is every request in a deployment that has enabled none of the parameters the other fields exist for.

The RFC 8707 resource list, the RFC 9396 authorization_details and the RFC 9449 DPoP header are public fields on the returned value, so a host’s token endpoint reads as the sequence of parameters it actually found on the wire.

pub fn with_resources(self, resources: &'a [String]) -> Self

The RFC 8707 resource parameters the request carried, in wire order.

pub fn with_authorization_details(self, authorization_details: &'a str) -> Self

The RFC 9396 authorization_details parameter, raw and unparsed. Available in every build: without rar what it buys is a REFUSAL rather than a grant, which is what RFC 9396 section 5 asks of a server that supports no detail type.

pub fn with_dpop_proof(self, dpop_proof: &'a str) -> Self

Available on crate feature dpop only.

The RFC 9449 DPoP request header, verbatim.

Trait Implementations

impl<'a> Clone for TokenRequestContext<'a>

fn clone(&self) -> TokenRequestContext<'a>

Returns a duplicate of the value.

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

Performs copy-assignment from source.

impl<'a> Copy for TokenRequestContext<'a>

impl<'a> Debug for TokenRequestContext<'a>

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

Formats the value using the given formatter.

impl<'a> Default for TokenRequestContext<'a>

fn default() -> TokenRequestContext<'a>

Returns the “default value” for a type.