Module oxide_auth::code_grant::frontend

General algorithms for frontends.

The frontend is concerned with executing the abstract behaviours given by the backend in terms of the actions of the frontend types. This means translating Redirect errors to the correct Redirect http response for example or optionally sending internal errors to loggers.

To ensure the adherence to the oauth2 rfc and the improve general implementations, some control flow of incoming packets is specified here instead of the frontend implementations. Instead, traits are offered to make this compatible with other frontends. In theory, this makes the frontend pluggable which could improve testing.

Custom frontend

In order to not place restrictions on the web server library in use, it is possible to implement a frontend completely with user defined types.

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 http (although there are currently discussions to consider communication to localhost as always occuring in a secure context).

After receiving an authorization grant, access token or access request, initiate the respective flow by collecting the Authorizer, Issuer, and Registrar instances. For example:

extern crate oxide_auth;
use oxide_auth::code_grant::frontend::{WebRequest, WebResponse, OAuthError};
use oxide_auth::code_grant::frontend::{IssuerRef, GrantFlow};
use oxide_auth::primitives::prelude::*;
use url::Url;
struct MyRequest { /* user defined */ }
struct MyResponse { /* user defined */ }

impl WebRequest for MyRequest {
    type Error = OAuthError; /* Custom type permitted but this is easier */
    type Response = MyResponse;
    /* Implementation of the traits' methods */
}

impl WebResponse for MyResponse {
    type Error = OAuthError;
    /* Implementation of the traits' methods */
}

struct State<'a> {
    registrar: &'a mut Registrar,
    authorizer: &'a mut Authorizer,
    issuer: &'a mut Issuer,
}

fn handle(state: State, request: &mut MyRequest) -> Result<MyResponse, OAuthError> {
    GrantFlow::new(state.registrar, state.authorizer, state.issuer)
        .handle(request)
}

Reexports

pub use super::backend::CodeRef;

pub use super::backend::ErrorUrl;

pub use super::backend::IssuerRef;

pub use super::backend::GuardRef;

Structs

AccessFlow	All relevant methods for checking authorization for access to a resource.
AuthorizationFlow	All relevant methods for handling authorization code requests.
GrantFlow	All relevant methods for granting access token from authorization codes.

Enums

Authentication	Answer from OwnerAuthorizer to indicate the owners choice.
OAuthError	Errors which should not or need not be communicated to the requesting party but which are of interest to the server. See the documentation for each enum variant for more documentation on each as some may have an expected response. These include badly formatted headers or url encoded body, unexpected parameters, or security relevant required parameters.

Traits

OwnerAuthorizer	Some instance which can decide the owners approval based on the request.
WebRequest	Abstraction of web requests with several different abstractions and constructors needed by this frontend. It is assumed to originate from an HTTP request, as defined in the scope of the rfc, but theoretically other requests are possible.
WebResponse	Response representation into which the Request is transformed by the code_grant types.