Aliri

Esperanto for "access"

Aliri is a family of crates intended to help build access control,
particularly of web APIs, where a token is the primary means of providing
access.

Features

The aliri crate provides primary support for the JavaScript/JSON
Object Signing and Encryption (JOSE) standard. For more information about the
RFCs relating to this standard, see the
crate's documentation.

The aliri_oauth2 crate provides some support for incorporating checks to
ensure a bearer of a token has sufficient scopes to permit access. It also
provides some functionality for using a local or remote JSON Web Key Set
(JWKS) as an authority to authenticate tokens. Some of this functionality maybe
broken off as part of planned OpenID Connect (OIDC) functionality.

The aliri_actix crate provides some useful bindings to create scope guards
for the actix-web web server.

Similarly, the aliri_warp crate provides bindings to the warp web
server, and includes filters useful for authenticating access to endpoints.

Other crates under the aliri header provide supporting functionality to these
primary crates.

JSON Web Signature (JWS) operations

Supported algorithms

Feature hmac:

HS256, HS384, HS512

Feature rsa:

RS256, RS384, RS512
PS256, PS384, PS512

Feature ec:

ES256, ES384

Note: none is explicitly not supported by this library due to the security
holes that algorithm raises when improperly accepted.

Support for private keys, to allow for signing operations and to generate new
keys, is provided by the private-keys feature.

Due to limitations in the ability to import and export generated keys in the
required JWK form, openssl is used to extract or handle the required
parameters. In addition, ring does not support RSA private keys that are
missing the p, q, dmp1, dmq1, or iqmp values. These parameters are
highly recommended as they speed up signature calculation, but according to
the JWA specification are technically optional.

Supported checks

iss exact string match
aud exact string match (list)
sub regex match
jti predicate function
nbf against current time
exp against current time
iat max age check
alg exact match (list)

Future plans

Support JWE
Support OpenID Connect as a relying party
Support obtaining tokens and token management

Alternatives

This set of crates grew out of my prior use of jsonwebtoken, and was expanded
to fit larger goals of implementing the full JOSE suite. Further inspiration was
taken from jsonwebtokens, in particular the Verifier type.

Unsafe code

Aliri does make use of very limited unsafe code. This unsafe code is limited
to a single function defined in macros that is used to generate strongly-typed
wrappers for String and Vec<u8> values. Unsafe is necessary here for the
reference types, in order to reinterpret the &str as &MyTypeRef or &[u8]
as &Base64Ref. This reinterpretation is safe because the wrappers around str
use #[repr(transparent)], which means that the wrappers share the exact same
representation as the underlying slice.

For the above reason, some included crates use #![deny(unsafe_code)]
rather than #![forbid(unsafe_code)]. The only #![allow(unsafe_code)] in
the code base can be found in the typed_string! and b64_builder! macros.

I have made this choice because of my preference for strongly-typed APIs over
stringly-typed APIs. I believe that consumers of this library will benefit
from this choice, as it will help them to prevent silly bugs.

Note that, because cargo-geiger has difficulty parsing out unsafe usage from
within macros, that tool won't report these crates as "radioactive", but
probably should. Do your due diligence.

thesn10/aliri