Crate oauth2

This is an OAuth 2.0 library for the Rust language. It defines types and traits useful for implementing an OAuth 2.0 compliant system as specified by RFC 6749.

The current implementation allows you to build the most common and most secure type of OAuth 2.0 infrastructure, but is not complete, and may not be absolutely correct. Please file bug reports or pull requests if you notice any deviation from RFC 6749, or if you have any other issues.

Stability Note

This library is still undergoing heavy upheaval. I don't recommend using it yet unless you are a masochist. -Mike, 25 May 2016

Applicability

OAuth 2.0 is a protocol framework that allows an application (the Client, usually a web site) to obtain limited access to an HTTP service (the Resource Server) on behalf of a Resource Owner which interacts with the Client via a User-Agent (browser). This is mediated via an Authorization Server (which could be the Resource Server itself, or separated from it).

The term "client" can be confusing here. The client of the OAuth service is typically a web site. The client of that web site is the user-agent (browser). To minimize confusion, the user-agent will not be referred to as a client.

OAuth is a Framework Only

OAuth 2.0 is an Authorization Framework. In order to get something usable, you must supply the missing pieces. And there are quite a few missing pieces which you will need to implement in order to get a working system. These include:

• Initial client registration (between the Client and the Authorization Server). Often people just use config files, but this is for you to decide.
• Storing state. Often database tables are used. Manytimes the Authorization Server and Resource Server use the same database, or perhaps are the same server. This is out of scope, and left up to you.
• User-Agent authentication and authorization (by the Authorization Server), where you should not only authenticate the resource owner, but also ask them if they really want to allow the client to have the rights to act on their behalf under the Scope requested.

Sample Implementation

Please see tests/lib.rs for a sample implementation.

Coverage and Standard Support

We do not (and likely will not) support every standard compliant way to use OAuth 2.0. But we will try to be as flexible as possible, and extend this library as time and resources allow. That being said, the following limitations currently apply:

• We only explicitly support the "authorization code" grant type, which is the most common and most secure. "Implicit", "resource owner password credentials", and "client credentials" grant types are not supported.
• The authorization server acts on behalf of the resource server, so virtually we are not supporting independent resource servers.
• We do not enforce that traffic be protected via TLS, although the standard requires that most (and suggests all) traffic be so protected. This is left up to the user.
• All IDs and tokens are taken to be respresented in UTF-8 encodings. We will not work with other encodings. The standard is silent on most encoding issues.
• Refresh tokens are not yet supported
• I'm not sure that the HTTP Status Codes returned to the user-agent on various failures are appropriate.
• FIXME: More limitations will be added to this list as the development progresses.

Reexports

pub use authz_server::AuthzServer;

pub use authz_request_data::AuthzRequestData;

pub use authz_error::{AuthzError, AuthzErrorCode};

pub use token_data::TokenData;

pub use token_error::{TokenError, TokenErrorCode};

pub use client::Client;

pub use client_type::ClientType;

pub use client_data::ClientData;

pub use error::{OAuthError, UserError};

Modules

authz_error
authz_request_data
authz_server
client
client_data
client_type
error
syntax	Syntax validation for OAuth 2.0 elements
token_data
token_error