oxide_auth/code_grant/
mod.rs

1//! Available backend algorithms.
2//!
3//! The backend codifies the requirements for the  from the [RFC 6749] into types and functions as
4//! safely as possible. The result of the backend are abstract results, actions which should be
5//! executed or relayed by the frontend using its available types. Abstract in this sense means
6//! that the reponses from the backend are not generic on an input type.
7//!
8//! Another consideration is the possiblilty of reusing some components with other oauth schemes.
9//! In this way, the backend is used to group necessary types and as an interface to implementors,
10//! to be able to infer the range of applicable end effectors (i.e. authorizers, issuer,
11//! registrars).
12//!
13//! ## Usage
14//!
15//! For all purposes that offer user interaction through an access point, you should probably have
16//! a look at the encapsulation provided by [`endpoint`] instead. You should only fallback to this
17//! if the flows provided there are too generic (unlikely) or your use case makes an [`Endpoint`]
18//! implementation impossible.
19//!
20//! ## Limitations
21//!
22//! The only supported authentication method for clients is password based. This is not to be
23//! confused with users in the sense of people registering accounts on a social media platform. In
24//! OAuth nomenclature, those are resource owners while a client is a user of a (Bearer) token.
25//!
26//! [RFC 6479]: https://tools.ietf.org/html/rfc6749
27//! [`endpoint`]: ../endpoint/index.html
28//! [`Endpoint`]: ../endpoint/trait.Endpoint.html
29
30pub mod accesstoken;
31pub mod authorization;
32pub mod client_credentials;
33pub mod error;
34pub mod extensions;
35pub mod refresh;
36pub mod resource;
oxide_auth/code_grant/mod.rs

oxide_auth/code_grant/
mod.rs
