decode - 如何解码Skype for Business服务返回的访问 token

Question

根据[Skype for Business Authentication]
https://ucwa.skype.com/documentation/GettingStarted-Authentication，我们可以通过oauth服务获取oauth访问 token 。访问 token 如下所示:

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

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

Answer 1

你是什​​么意思，怎么解码？ CBOR Web token 是一种易于阅读的格式。

请参阅RFC，尤其是此处的示例:
https://tools.ietf.org/html/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数组[

[Item 0]-受保护的部分。 CBOR编码的字节字符串。具有有效负载的声明，例如使用了哪种加密或签名。此部分是通过签名计算得出的，因此不能由第三方更改。

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

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

[项目3]-签名。 CBOR编码的字节字符串。这是protected + payload部分的签名。

] 结束

一些注意事项:

1. 如果注意，您会注意到CBOR CWT是一个CBOR框，其中包含一个字节字符串，一个映射，一个字节字符串和一个字节字符串，其中所有字节字符串都是单独的CBOR编码映射。不按照逻辑顺序将实际地图放在第一位或最后一位。您“只是”需要知道我们要打开它，对第一个CBOR字节字符串进行解码，这意味着“受保护”是具有特殊键/值对的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是算法，但值1也可能意味着另一部分中的ISSUER。也许如果您要采用无模式格式并对其应用模式，则可以从始终采用的模式格式开始？时间将证明CWT的方法是否在IoT和其他受限设备中流行。

4. 我的示例不足以解码。但是您发布的BASE64以0xD9 0x8A 0x2D ...开头，这是有效的CBOR项，表示TAG 0x8A2D。但是，这非常可疑，因为它可能是未分配区域中的标签TAG35373。如果这是一个真实的示例，我只能在这一点上猜测用户正在尝试通过在非指定区域使用标准来混淆某些意图。标准方式。实际的CWT通常应使用标签16、17、18或61。请参阅此链接以获取CBOR分配的标签 http://cbor.schmorp.de/stringref ...编辑:刚刚看到这是Skype for Business token !好吧，这可能不是混淆，但我真的无法猜测为什么它们似乎在替代标准所提供的东西。