pub trait AuthorizationCodeStore: Send + Sync {
// Required methods
fn issue(&self, code: AuthorizationCodeRecord) -> String;
fn redeem(&self, code: &str) -> Option<AuthorizationCodeRecord>;
fn revoke_account(&self, did: &str);
fn revoke_client(&self, client_id: &str, did: Option<&str>) -> usize;
}Expand description
Where authorization codes live between consent confirmation and exchange.
Required Methods§
Sourcefn issue(&self, code: AuthorizationCodeRecord) -> String
fn issue(&self, code: AuthorizationCodeRecord) -> String
Mints and stores a code for a confirmed grant.
Sourcefn redeem(&self, code: &str) -> Option<AuthorizationCodeRecord>
fn redeem(&self, code: &str) -> Option<AuthorizationCodeRecord>
Redeems a code. One-shot: RFC 6749 §4.1.2 requires a code be usable
once, and a second presentation of an already-redeemed code is
itself a signal the server treats as invalid_grant rather than as
“return the same tokens again.”
Sourcefn revoke_account(&self, did: &str)
fn revoke_account(&self, did: &str)
Drops every unredeemed code this store holds for did.
A code is one hop short of a token: redeeming one mints the grant
OAuthTokenStore::revoke_account would otherwise have to end a
moment later. Dropping the codes at the same time a deletion ends the
grants closes that hop, so nothing outstanding at deletion can turn
into a credential afterwards.
Sourcefn revoke_client(&self, client_id: &str, did: Option<&str>) -> usize
fn revoke_client(&self, client_id: &str, did: Option<&str>) -> usize
Drops every unredeemed code this store holds for client_id, or
for client_id on did alone. Answers how many went.
What an operator ending an app’s logins calls, for the same reason
Self::revoke_account exists: a code left behind would turn into
a fresh token a moment after the grants ended.