#[non_exhaustive]pub struct ParConfig {
pub pushed_authorization_request_endpoint: Option<String>,
pub request_uri_ttl: Duration,
pub require_pushed_authorization_requests: bool,
}par and (crate features jar or par) only.Expand description
RFC 9126 configuration. None on crate::server::ServerConfig::par means PAR is OFF: no
endpoint is advertised and AuthorizationServer::pushed_authorization_request refuses.
#[non_exhaustive], for the reason crate::server::ServerConfig carries it, and stated
plainly because this type is the exception to that finding rather than an instance of it: no
field here is feature gated TODAY. It is a configuration struct hanging off ServerConfig, it
is where every future RFC 9126 policy knob will land, and a host that learns the rule from the
parent config is entitled to it from the child. Construct with ParConfig::new and override
what the deployment needs.
Fields (Non-exhaustive)§
This struct is marked as non-exhaustive
Struct { .. } syntax; cannot be matched against without a wildcard ..; and struct update syntax will not work.RFC 9126 section 5 pushed_authorization_request_endpoint. None derives
{issuer}/par.
request_uri_ttl: DurationHow long a minted request_uri stays usable.
RFC 9126 section 2.2 leaves this to the server and gives 5 to 600 seconds as the typical
range. The default here is 60 seconds, which is a redirect round trip with room to spare:
the handle exists only to get the user agent from the client to this server’s authorization
endpoint, and everything the handle protects (the code_challenge above all) is worth less
the shorter it is guessable for.
RFC 9126 section 5 require_pushed_authorization_requests. When true, this server refuses
any authorization request whose parameters arrived in the query
(AuthorizationServer::validate_authorization_request answers invalid_request), which
is the section 4 policy statement that PAR is the only way in.