|0.6.2||May 27, 2023|
|0.6.1||Nov 28, 2022|
|0.6.0||Jun 15, 2022|
|0.5.6||Mar 18, 2022|
|0.1.0||Jun 24, 2020|
#52 in Authentication
1,212 downloads per month
Used in 7 crates (6 directly)
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.
Object Signing and Encryption (JOSE) standard. For more information about the
RFCs relating to this standard, see 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.
Other crates under the
aliri header provide supporting functionality to these
JSON Web Signature (JWS) operations
- HS256, HS384, HS512
- RS256, RS384, RS512
- PS256, PS384, PS512
- ES256, ES384
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
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
iqmp values. These parameters are
highly recommended as they speed up signature calculation, but according to
the JWA specification are technically optional.
issexact string match
audexact string match (list)
nbfagainst current time
expagainst current time
iatmax age check
algexact match (list)
- Support JWE
- Support OpenID Connect as a relying party
- Support obtaining tokens and token management
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
jsonwebtokens, in particular the
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
Vec<u8> values. Unsafe is necessary here for the
reference types, in order to reinterpret the
&Base64Ref. This reinterpretation is safe because the wrappers around
#[repr(transparent)], which means that the wrappers share the exact same
representation as the underlying slice.
For the above reason, some included crates use
#![forbid(unsafe_code)]. The only
the code base can be found in the
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.