#[non_exhaustive]pub struct AuthorizationRequest<'a> {
pub response_type: Option<Cow<'a, str>>,
pub client_id: Option<Cow<'a, str>>,
pub redirect_uri: Option<Cow<'a, str>>,
pub scope: Option<Cow<'a, str>>,
pub state: Option<Cow<'a, str>>,
pub code_challenge: Option<Cow<'a, str>>,
pub code_challenge_method: Option<Cow<'a, str>>,
pub resource: Vec<Cow<'a, str>>,
pub authorization_details: Option<Cow<'a, str>>,
pub acr_values: Option<Cow<'a, str>>,
pub max_age: Option<Cow<'a, str>>,
}Expand description
The raw authorization request as it arrives on the wire (RFC 6749 section 4.1.1 plus the RFC
7636 PKCE parameters). The host parses its query string into this; every member is optional
because every member can be absent in a real (invalid) request.
#[non_exhaustive]: rar adds authorization_details and consent adds two more, and the
doc above explains why they live here rather than being read off the query separately, which
means this type is where every future authorization parameter lands as well.
AuthorizationRequest::from_pairs is the path a host actually wants: it takes the decoded
query pairs and applies the section 3.1 rules about unknown and repeated parameters, which a
struct literal assembled by hand does not. For a request built in code rather than parsed, start
from Default::default() and assign; every field is public and every field is legitimately
absent, so there is nothing a literal could express that this cannot.
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.response_type: Option<Cow<'a, str>>Must be code.
client_id: Option<Cow<'a, str>>The requesting client.
redirect_uri: Option<Cow<'a, str>>Requested redirect target; must exact-match a registered URI when present.
scope: Option<Cow<'a, str>>Requested scope, space delimited; absent means the client’s registered default.
state: Option<Cow<'a, str>>Opaque client state, echoed back verbatim.
code_challenge: Option<Cow<'a, str>>The PKCE challenge (REQUIRED in OAuth 2.1 for the authorization code grant).
code_challenge_method: Option<Cow<'a, str>>The PKCE method; only S256.
resource: Vec<Cow<'a, str>>RFC 8707 resource indicators: the resource server(s) the client intends the issued token to be used at.
A Vec rather than an Option<Cow> because RFC 8707 section 2 says the parameter MAY be
repeated, and a client naming two resource servers means both, not the last one. An empty
Vec allocates nothing, so a request that carries no resource still costs what it did
before this parameter existed.
RFC 9396 section 2 authorization_details: a JSON array of objects, each naming a
type that defines the rest of it.
RAW TEXT, not a parsed structure, for the reason the rest of this type is raw text:
a server cannot reject what it cannot represent, and this parameter’s failure modes
(unparseable, oversized, an unknown type) all have to reach the state machine so it
can answer them the way RFC 9396 section 5 prescribes. Parsing happens in
crate::rar::AuthorizationDetails::parse, under this crate’s bounds, and only the
validated form carries the result.
NOT FEATURE GATED, which is the same decision crate::ErrorCode::InvalidAuthorizationDetails
records for the error code and taken for the same reason. Without rar this crate supports
no authorization detail type at all, so RFC 9396 section 5’s condition is met by EVERY
request that carries the parameter and every one of them has to be refused. A field that
disappeared with the feature left the parameter nowhere to land, and a parameter that lands
nowhere is a parameter accepted and ignored, which is the one outcome section 5 forbids.
So the field exists in every build; what changes with the feature is whether the value is
honoured or refused, and that is decided during validation, not during parsing.
acr_values: Option<Cow<'a, str>>consent only.RFC 9470 section 4 / OpenID Connect Core section 3.1.2.1 acr_values: the authentication
context classes the client will accept, space delimited, in order of preference.
ON THIS TYPE rather than parsed straight off the query, and that is the whole of the fix for a real gap. Every way into the authorization endpoint (a plain query, an RFC 9126 pushed request, an RFC 9101 signed request object) funnels through this struct, so a parameter that lives here is a parameter every path must carry; a parameter parsed separately from the query is a parameter the other two paths silently drop. That is exactly what happened to these two: PAR and JAR requests disabled step-up entirely, and for JAR the server was reading intermediary-rewritable query text on a request whose only purpose is that it cannot be rewritten (RFC 9101 section 6.3).
RAW TEXT for the same reason as the rest of this type, and parsed into
crate::consent::AuthenticationRequirement by validation.
max_age: Option<Cow<'a, str>>consent only.RFC 9470 section 4 / OpenID Connect Core section 3.1.2.1 max_age: how old the user’s
authentication may be, in seconds. See AuthorizationRequest::acr_values for why it is
a field here rather than something read off the query.
Implementations§
Source§impl<'a> AuthorizationRequest<'a>
impl<'a> AuthorizationRequest<'a>
Sourcepub fn from_pairs<I, K, V>(pairs: I) -> Self
pub fn from_pairs<I, K, V>(pairs: I) -> Self
Collect a request from already-decoded (name, value) query pairs.
Unknown parameters are ignored, which RFC 6749 section 3.1 requires. A repeated parameter keeps the FIRST occurrence: section 3.1 says a parameter MUST NOT appear more than once, and last-wins is the smuggling-friendly choice when two intermediaries disagree about which copy counts.
Trait Implementations§
Source§impl<'a> Clone for AuthorizationRequest<'a>
impl<'a> Clone for AuthorizationRequest<'a>
Source§fn clone(&self) -> AuthorizationRequest<'a>
fn clone(&self) -> AuthorizationRequest<'a>
1.0.0 (const: unstable) · Source§fn clone_from(&mut self, source: &Self)
fn clone_from(&mut self, source: &Self)
source. Read more