dcaf-rs

ACE-OAuth框架 (RFC 9200) 的实现。

此crate实现了在RFC 9200中定义的ACE-OAuth（使用OAuth 2.0框架的受限环境身份验证和授权）框架。主要功能包括CBOR-（反）序列化数据模型，如AccessTokenRequest，以及创建COSE加密/签名访问令牌的可能性（如标准中所述），以及解密/验证函数。必须由用户通过实现CoseEncryptCipher或CoseSignCipher来提供加密函数的实现。

请注意，实际上传输序列化值（例如，通过CoAP）或提供ACE-OAuth RFC中没有提到的更复杂的功能（例如，授权服务器的权限管理系统）超出了此crate的范围。这同样适用于前一段中提到的加密函数。

选择DCAF这个名字是因为最终，计划为此crate提供在Delegated CoAP Authentication and Authorization Framework (DCAF)中指定的功能，该框架在draft-gerdes-ace-dcaf-authorize中指定（在ACE-OAuth之前指定，并激发了其中许多设计选择）——具体来说，计划支持使用CAM（客户端授权管理器）而不是仅使用SAM（服务器授权管理器），就像在ACE-OAuth中做的那样。与现有的C语言中的DCAF实现（我们将称为libdcaf以区分dcaf，它指的是此crate）的兼容性也是一个额外的设计目标，尽管主要目标仍然是支持ACE-OAuth。

由于本软件包的一个可能的用例是在受限制的物联网设备上使用，因此需求最小化——因此，虽然仍然需要 alloc，但本软件包通过省略默认的 std 功能，提供了 no_std 支持。

用法

[dependencies]
dcaf = { version = "^0.3" }

或者，如果您计划在 no_std 环境中使用此软件包

[dependencies]
dcaf = { version = "^0.3", default-features = false }

示例

如前所述，本软件包的主要功能是 ACE-OAuth 数据模型和令牌创建/验证函数。我们将在这里快速介绍这两者。

数据模型

例如，假设您（客户端）希望从授权服务器请求访问令牌。为此，您需要创建一个 AccessTokenRequest，它至少需要包含一个 client_id。我们还将指定一个受众、作用域（使用 TextEncodedScope——注意，二进制编码的作用域或 AIF 编码的作用域也可以工作），以及一个 ProofOfPossessionKey（访问令牌应绑定到的密钥）在 req_cnf 字段中。

创建、序列化和反序列化此类结构将如下所示

use dcaf::{AccessTokenRequest, ToCborMap, ProofOfPossessionKey, TextEncodedScope};

let request = AccessTokenRequest::builder()
   .client_id("myclient")
   .audience("valve242")
   .scope(TextEncodedScope::try_from("read")?)
   .req_cnf(ProofOfPossessionKey::KeyId(base64::decode("6kg0dXJM13U")?))
   .build()?;
let mut encoded = Vec::new();
request.clone().serialize_into(&mut encoded)?;
assert_eq!(AccessTokenRequest::deserialize_from(encoded.as_slice())?, request);

访问令牌

在上一个示例之后，假设我们现在想要创建一个包含现有 key 以及关于令牌受众和发行者的声明的已签名访问令牌，使用现有的类型为 FakeCrypto[^cipher] 的加密器

use dcaf::token::CoseCipher;


let rng = FakeRng;
let key = CoseKeyBuilder::new_symmetric_key(vec![1,2,3,4,5]).key_id(vec![0xDC, 0xAF]).build();
let claims = ClaimsSetBuilder::new()
     .audience(String::from("coaps://rs.example.com"))
     .issuer(String::from("coaps://as.example.com"))
     .claim(CwtClaimName::Cnf, key.clone().to_cbor_value()?)
     .build();
let token = sign_access_token::<FakeCrypto, FakeRng>(&key, claims, None, None, None, rng)?;
assert!(verify_access_token::<FakeCrypto>(&key, &token, None).is_ok());

[^cipher]：注意，我们在此故意省略了关于 cipher 实现的细节，因为此类实现将不在本软件包的范围内。

提供的数据模型

令牌端点

最常用的模型可能是令牌端点的 AccessTokenRequest 和 AccessTokenResponse，如 RFC 9200 第 5.8 节 所述。在发生错误的情况下，应使用 ErrorResponse。

在初始未授权资源请求消息之后，可以使用 AuthServerRequestCreationHint 提供额外的信息给客户端，如 RFC 9200 第 5.3 节 所述。

常见数据类型

一些跨多个场景使用的类型包括

• Scope（如 RFC 9200 第 5.8.1 节 所述），可以是 TextEncodedScope、BinaryEncodedScope 或 AifEncodedScope。
• ProofOfPossessionKey，如RFC 8747第3.1节所述。例如，这将在访问令牌的cnf声明中使用。
• 虽然不是一种数据类型，但constants模块提供了代表在ACE-OAuth中使用的值的各个常量。

创建访问令牌

要创建访问令牌，您可以使用encrypt_access_token或sign_access_token，具体取决于您是否希望访问令牌被包装在COSE_Encrypt0或COSE_Sign1结构中。计划在未来支持两者的组合。如果您想要创建一个针对多个接收者（每个接收者都有自己的密钥）的令牌，您可以使用encrypt_access_token_multiple或sign_access_token_multiple。