Crate oxide_auth

oxide-auth

A OAuth2 server library, for use in combination with actix-web or other frontends, featuring a set of configurable and pluggable backends.

About

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.

The actix frontend, included as a default feature, provides bindings to create an endpoint in actix-web.

Example

A fully featured web server example is realized with actix.

$ cargo run --example actix

Use cases

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.

Create a web server with OAuth security

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 REST backend.

This library can be integrated into several different web server libraries. Most prominently actix-web, rocket and 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 frontends module.

You can also use this library with any HTTP frontend, see frontends::simple.

Custom Frontends

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 of WebRequest and WebResponse. WARNING: Custom frontends MUST ensure a secure communication layer with confidential clients. This means using TLS for communication over https.

For more information, see the documentation of endpoint and frontends.

Using the primitives

All 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 Send or Sync constraits due to limitations of the web library).

Modules

code_grant	Available backend algorithms.
endpoint	Polymorphic HTTP wrappers for code grant authorization and other flows.
frontends	Fully implemented frontends.
primitives	A collection of primites useful for more than one authorization method.