#jwt #jose #jwk #access-control #web-api #jwa

aliri

实现JavaScript/JSON对象签名和加密(JOSE)标准

15个版本

0.6.3 2024年4月12日
0.6.2 2023年5月27日
0.6.1 2022年11月28日
0.6.0 2022年6月15日
0.1.0 2020年6月24日

#29认证

Download history 33666/week @ 2024-04-27 45286/week @ 2024-05-04 40152/week @ 2024-05-11 38815/week @ 2024-05-18 32033/week @ 2024-05-25 29647/week @ 2024-06-01 31943/week @ 2024-06-08 33739/week @ 2024-06-15 35175/week @ 2024-06-22 27605/week @ 2024-06-29 32321/week @ 2024-07-06 33800/week @ 2024-07-13 31209/week @ 2024-07-20 26091/week @ 2024-07-27 23380/week @ 2024-08-03 20154/week @ 2024-08-10

106,350 每月下载
用于 7 个crates(6 个直接)

MIT/Apache

215KB
4.5K SLoC

Aliri

Esperanto中的"access"

CI

Aliri是一组crates,旨在帮助构建访问控制,特别是针对以令牌为主要访问手段的Web API。

特性

aliri crate为JavaScript/JSON对象签名和加密(JOSE)标准提供主要支持。有关与此标准相关的RFC的更多信息,请参阅crate的文档

aliri_oauth2 crate提供了一些支持,以确保令牌持有者拥有足够的作用域以允许访问。它还提供了一些使用本地或远程JSON Web密钥集(JWKS)作为认证令牌的权威的功能。其中一些功能可能作为计划中的OpenID Connect(OIDC)功能的一部分拆分。

aliri_actix crate提供了一些有用的绑定,用于创建actix-web Web服务器的范围守护者。

同样,aliri_warp crate提供了对warp Web服务器的绑定,并包括用于端点认证的有用过滤器。

aliri标题下的其他crates为这些主要crates提供支持功能。

JSON Web签名(JWS)操作

支持的算法

功能hmac

  • HS256, HS384, HS512

功能rsa

  • RS256, RS384, RS512
  • PS256, PS384, PS512

功能ec

  • ES256, ES384

注意:由于该算法在不当接受时产生的安全漏洞,显式不支持none

通过提供私钥支持,允许进行签名操作和生成新密钥,由private-keys功能提供。

由于在所需JWK格式中导入和导出生成密钥的能力有限,使用 openssl 来提取或处理所需参数。此外,ring 不支持缺少 pqdmp1dmq1iqmp 值的RSA私钥。这些参数 强烈推荐,因为它们可以加快签名计算速度,但根据JWA规范,这些参数在技术上是可以选择的。

支持检查

  • iss 精确字符串匹配
  • aud 精确字符串匹配(列表)
  • sub 正则表达式匹配
  • jti 断言函数
  • nbf 与当前时间比较
  • exp 与当前时间比较
  • iat 最大年龄检查
  • alg 精确匹配(列表)

未来计划

  • 支持JWE
  • 支持作为受信任方的OpenID Connect
  • 支持获取令牌和令牌管理

替代方案

这个crate集是从我对 jsonwebtoken 的先前使用中发展而来的,并扩展以适应实现整个JOSE套件的目标。进一步的灵感来自 jsonwebtokens,特别是 Verifier 类型。

不安全代码

Aliri 实际上只使用了非常有限的不安全代码。这些不安全代码仅限于在宏中定义的单个函数,该函数用于为 StringVec<u8> 值生成强类型包装器。由于需要引用类型,因此不安全是必要的,以便将 &str 重新解释为 &MyTypeRef 或将 &[u8] 重新解释为 &Base64Ref。这种重新解释是安全的,因为围绕 str 的包装器使用 #[repr(transparent)],这意味着包装器与底层切片具有完全相同的表示。

由于上述原因,一些包含的crate使用 #![deny(unsafe_code)] 而不是 #![forbid(unsafe_code)]。代码库中唯一的 #![allow(unsafe_code)] 可以在 typed_string!b64_builder! 宏中找到。

我之所以做出这个选择,是因为我更喜欢 强类型 API 而不是 字符串类型 API。我相信,使用这个库的开发者将从这个选择中受益,因为它将帮助他们防止愚蠢的错误。

请注意,由于 cargo-geiger 在宏内部难以解析出不安全的使用,该工具不会将这些crate报告为“放射性”,但实际上应该这样。 请务必进行尽职调查。

依赖项

~8–19MB
~333K SLoC