Struct ValidatedAuthorizationRequest 

pub struct ValidatedAuthorizationRequest {
    pub client_id: ClientId,
    pub redirect_uri: String,
    pub redirect_uri_was_explicit: bool,
    pub scope: ScopeSet,
    pub state: Option<String>,
    pub code_challenge: String,
    pub code_challenge_method: CodeChallengeMethod,
    pub issuer: String,
    pub resource: Vec<String>,
    pub authorization_details: AuthorizationDetails,
    pub authentication_requirement: AuthenticationRequirement,
    /* private fields */
}

A request that has passed validation: the client exists, is allowed this grant, the redirect URI is one of its registrations, and the PKCE parameters are well formed.

The data fields stay pub for read access (state, ergonomics, and the smallest diff over the existing call sites in tests/authorization_code.rs, none of which construct this type by hand). What actually enforces “only a validated request can mint a code” is the private _sealed field below: because it is not pub, no struct-literal expression written outside this module (that includes every downstream host, since this module is the only one with access to Sealed) can name every field of this struct, so a ValidatedAuthorizationRequest can only come from the crate-private ValidatedAuthorizationRequest::new, which only AuthorizationServer::validate_authorization_request (in server.rs, within this crate) calls. That is what “cannot be spelled” now actually means: not “the fields are private” (they are not), but “the value cannot be produced without going through validation first.”

Fields

client_id: ClientId

The validated client.

redirect_uri: String

The exact registered redirect URI this request resolved to.

redirect_uri_was_explicit: bool

Whether the authorization REQUEST named the redirect URI itself, as opposed to omitting it and being filled in from the client’s single registration (RFC 6749 section 3.1.2.3).

Carried onto AuthorizationCodeRecord::redirect_uri_was_explicit, because RFC 6749 section 4.1.3 makes the token endpoint’s redirect_uri parameter REQUIRED “if the redirect_uri parameter was included in the authorization request” and not otherwise. The resolved URI above cannot answer that: it is filled in either way, so by the time the token endpoint sees the record the two cases are indistinguishable without this.

scope: ScopeSet

The scope that will be granted on approval.

state: Option<String>

The request’s state, to be echoed on either outcome.

code_challenge: String

The PKCE challenge to record against the issued code.

code_challenge_method: CodeChallengeMethod

The PKCE method (only S256).

issuer: String

This server’s issuer identifier, carried so that the authorization response can name its author (RFC 9207 section 2).

It is on the VALIDATED request rather than looked up at response time because ValidatedAuthorizationRequest::denied is also an authorization response and has no access to the server’s configuration: a refusal that could not say who refused would be exactly the gap RFC 9207 section 2.2 closes.

resource: Vec<String>

The RFC 8707 resource indicators this request asked for, already validated. Empty when the client named none, which means the issued token carries no audience restriction from this mechanism.

authorization_details: AuthorizationDetails

Available on crate feature rar only.

The RFC 9396 authorization details this request asked for, already parsed and already checked against the server’s supported types (section 5). Empty when the client named none.

A host’s consent screen MAY replace this before the code is issued: RFC 9396 section 7.1 is explicit that the details attached to the token may differ from the request, which is how an AS records the account the user actually picked.

authentication_requirement: AuthenticationRequirement

Available on crate feature consent only.

The RFC 9470 step-up requirement this request carried, already parsed.

It rides on the VALIDATED request so that there is exactly ONE source of it per path, and that source is the request that was actually resolved: the pushed record for a PAR request, the signed claim set for a JAR request, the query for a plain one. Anything that reads the query separately is reading the wrong thing for two of the three (RFC 9126 section 4, RFC 9101 section 6.3).

Empty means the client asked for no step-up, which is what an ordinary request carries.

Implementations

impl ValidatedAuthorizationRequest

pub fn denied(&self) -> AuthorizationErrorRedirect

The redirect describing the user refusing consent (RFC 6749 section 4.1.2.1 access_denied). A refusal is an answer the client is entitled to receive, not an error page.

Trait Implementations

impl Clone for ValidatedAuthorizationRequest

fn clone(&self) -> ValidatedAuthorizationRequest

Returns a duplicate of the value.

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

Performs copy-assignment from source.

impl Debug for ValidatedAuthorizationRequest

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

Formats the value using the given formatter.

impl Eq for ValidatedAuthorizationRequest

impl PartialEq for ValidatedAuthorizationRequest

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

Equality operator ==.

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

Inequality operator !=.

impl StructuralPartialEq for ValidatedAuthorizationRequest