10 releases
0.3.1 | Apr 12, 2024 |
---|---|
0.2.3 | May 27, 2023 |
0.2.2 | Nov 28, 2022 |
0.2.1 | Aug 10, 2022 |
0.1.0 | Jun 3, 2021 |
#489 in Authentication
93,446 downloads per month
Used in aliri_reqwest
250KB
5.5K
SLoC
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 matchaud
exact string match (list)sub
regex matchjti
predicate functionnbf
against current timeexp
against current timeiat
max age checkalg
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.
Dependencies
~11–23MB
~425K SLoC