Skip to main content

Module redeem

Module redeem 

Source
Expand description

Completing the authorization-code exchange: trading the code for a token.

begin_authorization sends the user somewhere, and authorize_callback validates what comes back. Neither of those produces a token, and this is the step that does.

§The request is assembled, never supplied

Every parameter of the token request is read off the AuthorizedCode — the value the callback step produced — rather than passed in by the caller. That is not tidiness. RFC 6749 §4.1.3 requires the redirect_uri to be identical to the one in the authorization request, and a caller that supplies it separately can supply a different one. The same goes for the code_verifier: presenting anything other than the value the code_challenge was derived from is a failed PKCE check, and the failure is the server refusing a code the client genuinely owns.

§The code is consumed, so it cannot be spent twice

redeem takes the AuthorizedCode by value, and AuthorizedCode is not Clone, so one value cannot be redeemed twice. A retry after a dropped connection — the case where the first attempt may already have been honoured — therefore cannot silently spend the same code again.

That is the whole of the guarantee, and it is narrower than “a code is used once”. A caller that runs authorize_callback twice against the same PendingAuthorization holds two values and may try both; RFC 6749 §4.1.2 requires the authorization server to deny the second. The type closes the accident, the server closes the choice.

Structs§

RefreshRequest
One grant_type=refresh_token request.
TokenRequest
One token request, assembled from an AuthorizedCode and a registration.

Enums§

RedeemError
Why redeem did not produce a token.
TokenEndpointError
Why a redemption did not produce a token.

Traits§

TokenEndpoint
Asks an authorization server to trade a code for a token.

Functions§

redeem
Trade a validated authorization code for a token.
redeem_with_scope
redeem, sending scope with the token request.