Module client 

Beginning an OAuth authorization flow: what the client sends the user to, and what it must keep until the user comes back.

The half that happens in a browser

GET the authorization endpoint, the user authenticates there, and the authorization server redirects to the client’s registered redirect URI with a code and a state. Between those two points the client holds two secrets it generated and must not lose: the state that proves this callback belongs to this request, and the PKCE code_verifier that the code_challenge was derived from.

Both are redacted under Debug on PendingAuthorization, because that value is the one a client will hold in memory for the whole user-visible round trip, and it is exactly the value a panic message, an assert_eq! or a future log line would otherwise render.

What this deliberately does not do

It does not redeem the code, and it does not talk to the authorization server. PendingAuthorization is the value that survives the redirect; a separate use case consumes it with the callback and owns the token request. Splitting them is what lets the same pending value be tested against a recorded callback without a socket.

Structs

PendingAuthorization

Everything a client must keep between sending the user away and handling the callback.

State

An OAuth state value: the nonce tying one authorization response to one request.

Enums

BeginError

Why an authorization request could not be started.

SecretError

A source of unguessable values could not produce one.

Traits

AuthorizationSecrets

A source of the unguessable values an authorization request is built from.

Functions

begin_authorization

Build the authorization request and the state a client must keep for it.