An OAuth2 server library, for use in combination with actix-web or other front-ends, featuring a set of configurable and pluggable back-ends.
oxide-auth aims at providing a comprehensive and extensible interface to managing OAuth2
tokens on a server. This depends on both a front-end facing web server for network operations
and a back-end implementation for policies and data storage. The main interface is designed
around traits in both directions, so that the front-end is as easily pluggable as the back-end.
There are many adaptations for specific web server crates (
rouille) in associated crates
So you want to build a new OAuth provider? Instead of only relying on tokens provided by other
large internet entities, you want to make your own tokens? Examples of this use case: A web
facing data portal, automation endpoints (in the style of Reddit or Discord), or even to
restrict the authorization of different components of your own software by applying these
techniques to your
Next, a set of
primitives needs to be chosen. These will depend on the policies need for
Your use case but will in general encompass a
Authorizer, and an
Issuer. There is a simple, in-memory implementation provided for each of those. More
complex solutions might require a customized trait implementation especially when specific
cryptographic standards or consistency requirements are needed. (It would be appreciated if
those were shared with the community as an open-source project, for example as a complementary
crate, but not mandatory).
And finally, an implementation of an
Endpoint is required, handling the request type that
has been chosen and forwarding it to the primitives. In very simple cases this can be an
instantiation of the
Generic struct. But for most complex cases it should instead be a
custom trait implementation that is tailored to Your specific requirements. Besides the
previously chosen primitives, the endpoint require You to choose two more interface: An
OwnerSolicitor to interact with Your session handling, user consent, and CSRF protection;
Scopes deciding required permissions for a request.
A key feature is the ability to add your own front-end without jeopardizing safety
requirements. For example to add your in-house server and request representation! This requires
custom, related implementations of
WebResponse. In theory, you are not
even restricted to HTTP as long as the parameters can be transmitted safely. WARNING: Custom
front-ends MUST ensure a secure transportation layer with confidential clients. This means
using TLS for communication over HTTPS.