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§
- Refresh
Request - One
grant_type=refresh_tokenrequest. - Token
Request - One token request, assembled from an
AuthorizedCodeand a registration.
Enums§
- Redeem
Error - Why
redeemdid not produce a token. - Token
Endpoint Error - Why a redemption did not produce a token.
Traits§
- Token
Endpoint - 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, sendingscopewith the token request.