3

根据【Skype for Business认证】 https://ucwa.skype.com/documentation/GettingStarted-Authentication，我们可以通过oauth服务获取oauth访问令牌。访问令牌如下所示：

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
{
  "access_token":"cwt=2YotnFZFEjr1zCsicMWpAA...",
  "token_type":"Bearer",
  "expires_in":3600
}

我想知道访问令牌是否确实是 CBOR Web 令牌 (CWT)，如果是，如何使用 python 或任何语言解码令牌。

4

2 回答 2

2

你是什​​么意思如何解码？CBOR Web 令牌是一种易于阅读的格式。

请参阅 RFC，特别是此处的示例： https ://www.rfc-editor.org/rfc/rfc8392#appendix-A.3

获取 CWT 字节字符串：

d28443a10126a104524173796d6d657472696345434453413235365850a70175636f61703a2f2f61732e6578616d706c652e636f6d02656572696b77037818636f61703a2f2f6c696768742e6578616d706c652e636f6d041a5612aeb0051a5610d9f0061a5610d9f007420b7158405427c1ff28d23fbad1f29c4c7c6a555e601d6fa29f9179bc3d7438bacaca5acd08c8d4d4f96131680c429a01f85951ecee743a52b9b63632c57209120e1c9e30

并通过http://CBOR.me的 CBOR 操场给出：

D2                                      # tag(18)
   84                                   # array(4)
      43                                # bytes(3)
         A10126
      A1                                # map(1)
         04                             # unsigned(4)
         52                             # bytes(18)
            4173796D6D65747269634543445341323536
      58 50                             # bytes(80)
         A70175636F61703A2F2F61732E6578616D706C652E636F6D02656572696B77037818636F61703A2F2F6C696768742E6578616D706C652E636F6D041A5612AEB0051A5610D9F0061A5610D9F007420B71 
      58 40                             # bytes(64)
         5427C1FF28D23FBAD1F29C4C7C6A555E601D6FA29F9179BC3D7438BACACA5ACD08C8D4D4F96131680C429A01F85951ECEE743A52B9B63632C57209120E1C9E30

关于在 CBOR.me 上使用 CBOR 游乐场的一个快速说明，它有时无法正确格式化墨盒返回或标签。它可以做一些奇怪的事情，比如从十六进制字节的中间掉一个半字节，太疯狂了。因此，在粘贴之前删除任何格式。

这是 RFC 显示为解码值的内容。（注意，解码 CBOR 时会丢失空格格式）

18(
     [
       / protected / << {
         / alg / 1: -7 / ECDSA 256 /
       } >>,
       / unprotected / {
         / kid / 4: h'4173796d6d657472696345434453413
                      23536' / 'AsymmetricECDSA256' /
       },
       / payload / << {
         / iss / 1: "coap://as.example.com",
         / sub / 2: "erikw",
         / aud / 3: "coap://light.example.com",
         / exp / 4: 1444064944,
         / nbf / 5: 1443944944,
         / iat / 6: 1443944944,
         / cti / 7: h'0b71'
       } >>,
       / signature / h'5427c1ff28d23fbad1f29c4c7c6a555e601d6fa29f
                       9179bc3d7438bacaca5acd08c8d4d4f96131680c42
                       9a01f85951ecee743a52b9b63632c57209120e1c9e
                       30'
     ]
   )

现在，关于 CBOR COSE/CWT 格式本身。

5秒分解是这样的：

CWT 是一个包含 4 个项目的外部 CBOR 数组 [

  • [项目 0] - 受保护部分。一个 CBOR 编码的字节串。使用有效负载的声明，例如使用了哪种加密或签名。此部分是使用签名计算的，因此第三方无法更改。

  • 第 1 项 - 未受保护的部分。CBOR 地图。这包含其他声明，通常是与加密相关的有用数据，供您用来理解有效负载。您也可以在此处添加自己的数据。这部分在计算签名时没有带入，因此得名“unprotected”。

  • [项目 2] - 有效载荷。一个 CBOR 编码的字节串。这是您最感兴趣的部分。在签名消息上，这当然是在计算签名时引入的。对于加密消息，这将是唯一的加密部分。可能是加垫的。请注意，某些解码器处理额外字节/填充的方式可能与其他解码器不同。

  • [第 3 项] - 签名。一个 CBOR 编码的字节串。这是受保护+有效负载部分的签名。

] 结尾

几点注意事项：

1.如果您注意的话，您会注意到 CBOR CWT 是一个 CBOR 框，其中包含一个字节串、一个映射、一个字节串和一个字节串，其中所有字节串都是单独的 CBOR 编码映射。不是按照将实际地图放在首位或最后的逻辑顺序。你“只是”需要知道我们要打开它，解码第一个 CBOR 字节字符串，它意味着 Protected，它是一个带有特殊键/值对的 CBOR 映射本身（参见注释 #3），然后是未受保护的 MAP声明，另外两个 CBOR 字符串表示有效负载和签名，并且由于 JOSE/JWT/COSE/CWT 允许任意数量的加密和签名格式，您需要检查受保护和不受保护的部分，然后才能获得足够的信息来验证签名. 这一切都由你记住。你认为一种格式是“好”的吗 如果您需要“只知道”如何解释它？我相信这与 JSON 甚至 JWT 完全相反，尽管 JWT 是人类可读的，但它们只是在逻辑上布局。如果您不习惯数据，我认为 CWT 是一种相当高的熵格式。你的是我见过的第一个 CWT 真实世界的应用程序，我不希望看到更多。

2. COSE / CWT 规范建议使用“application/cwt”，因此当您收到一些字节数据包时，您就知道它是一个 CWT。很好，但是，在你上面的例子中，你有 "cwt=[some cwt]" 这意味着要解码你需要去掉 "cwt="，然后从 BASE64 转换为 HEX，然后像上面那样解码。我希望做这件事的人明白他们在应用协议时是多么错误地使用像 CBOR 这样的二进制格式在用 BASE64 表示时丢失了任何收益，对于相同的表示形式，它比二进制大 50%。通过使用“application/cwt”，您只需要显示十六进制字符串。在示例中，它们包括 CWT 之外的应用程序声明。

3. COSE 和 CWT 使用标签和标题引用来表示速记值。使用字母“kid”作为密钥标识将使用 4 个字节作为该地图/对象的名称进行编码。[string len 3, k, i, d] 所以他们使用引用来“提高效率”。在这种情况下，他们使用整数 2，其中 2 = 。这意味着映射的“名称”部分是一个字节。请注意，CBOR 允许您将数字分配给地图中的值，而 JSON 不允许，因此将 CBOR/CWT 转换为 JSON/JWT 会很乏味。阅读 RFC 并检查别名。这实际上是采用无模式 CBOR 并对其应用一层模式。我正在开发一个带有 CBOR 数据进出的嵌入式应用程序，我宁愿在每个地图上花费 2-4 个字节来拥有“i”或“iss”，而不是仅仅“必须记住”并获得我的另一个开发人员都知道受保护部分中的值 1 是 ALGORITHM，但值 1 也可能意味着另一个部分中的 ISSUER。也许如果您要采用无模式格式并对其应用模式，您可以从一致应用的模式格式开始？时间会证明 CWT 的方法是否会在物联网和其他受限设备中流行起来。

4.我没有足够的例子来解码。但是您发布的 BASE64 以 0xD9 0x8A 0x2D ... 开头，这是一个有效的 CBOR 项目，意思是 TAG 0x8A2D。但是，这是非常值得怀疑的，因为它将是未分配区域 TAG 35373 中的一个标签。如果这是一个真实的例子，我只能在这一点上猜测用户试图通过在非分配区域中使用标准来模糊某些意图。标准方式。真正的 CWT 通常应使用标签 16、17、18 或 61。请参阅此链接以获取 CBOR 分配的标签，http ://cbor.schmorp.de/stringref ... 编辑：刚刚看到这是一个 Skype for Business 令牌！？好吧，这可能不是混淆，但我真的无法猜测为什么他们似乎在弥补标准提供的东西的替代品。

于 2019-10-28T18:41:28.430 回答
1

有点晚了，但是由于这个话题是你搜索网络时发生的事情，我想插话。Skype for Business Authentication（MS RTC Authentication）返回的 CWT 不是 CBOR Web Token。它似乎是一种更古老的技术，称为 Compact Web Ticket。我不知道如何解析这些字符串的内容，但它既不是 JSON Web Token 也不是 CBOR Web Token。

于 2020-05-01T13:16:58.837 回答