A OAuth2 server library, for use in combination with actix-web or other frontends, featuring a set of configurable and pluggable backends.
oxide-auth aims at providing a comprehensive and extensible interface to managing oauth2
tokens on a server. While the core package is agnostic of the used frontend, an optional actix
adaptor is provided with the default configuration. Through an interface designed with traits,
the frontend is as easily pluggable as the backend.
actix frontend, included as a default feature, provides bindings to create an endpoint in
A fully featured web server example is realized with actix.
$ cargo run --example actix
Versatility is a primary goal. Consequently, there are several different scenarios in which this library will be useful. Of course all of them are related to server side use of OAuth2 protocol.
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? This library and OAuth2 was built to
safely provide authorization tokens to third-party clients, distinct from your users that
authorize them. 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
This library can be integrated into several different web server libraries. Most prominently
iron. These frontends allow you to easily answer OAuth requests and
secure protected resources, utilizing the library provided http request types. Some provide
additional abstractions for an integrated feeling.
A complete list can be found in the
You can also use this library with any HTTP frontend, see
A key feature is the ability to add your own frontend without jeopardizing safety requirements.
For example to add your in-house
REST library! This requires custom, related implementations
WebResponse. WARNING: Custom frontends MUST ensure a secure
communication layer with confidential clients. This means using TLS for communication over
primitives can be used independently of the frontend modules. This makes them reusable
for other authentication methods. But this works the other way around as well. Your own
implementations of these primitives can be used directly in conjuction with all frontends
(although some may impose
Sync constraits due to limitations of the web library).
Available backend algorithms.
Polymorphic HTTP wrappers for code grant authorization and other flows.
Fully implemented frontends.
A collection of primites useful for more than one authorization method.