根据[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或任何语言解码令牌。
答案 0 :(得分:1)
您是什么意思,如何解码? CBOR Web令牌是一种易于阅读的格式。
请参阅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地图。其中包含其他声明,通常是与加密相关的有用数据,供您用来理解有效负载。您也可以在此处添加自己的数据。计算签名时不会加入此部分,因此名称为“未保护”。
[项目2]-有效负载。 CBOR编码的字节字符串。这是您最感兴趣的部分。在签名消息中,这当然是在计算签名时引入的。对于加密的消息,这将是唯一的加密部分。可能会填充。请注意,某些解码器可能会以其他方式处理额外的字节/填充。
[项目3]-签名。 CBOR编码的字节字符串。这是protected + payload部分的签名。
]结束
一些注意事项:
1。。如果您注意的话,您会注意到CBOR CWT是一个CBOR框,其中包含一个字节字符串,一个映射,一个字节字符串和所有所有字节字符串都位于其中的字节字符串。单独的CBOR编码地图。不按照逻辑顺序将实际地图放在第一位或最后一位。您“只是”需要知道我们将要打开它,对第一个CBOR字节字符串进行解码,即“ Protected”,它是具有特殊键/值对的CBOR映射本身(请参见注释#3),然后是带有它的未受保护的MAP。声明,另外两个CBOR字符串分别表示有效载荷和签名,并且由于JOSE / JWT / COSE / CWT允许使用任何数量的加密和签名格式,因此,在拥有足够的信息来验证签名之前,您需要检查受保护和不受保护的部分。这一切都是您要记住的。如果您需要“只是知道”如何解释格式,您是否认为格式是“好”格式?我认为这与JSON甚至JWT都非常相反,尽管JJSON具有人类可读性,但它们在逻辑上只是布局。如果您不习惯使用数据,我认为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令牌!?嗯,这可能不是令人困惑,但我真的无法猜测为什么它们似乎在替代标准所提供的东西。
答案 1 :(得分:0)
已经有点晚了,但是由于这个主题是您在网上搜索时遇到的问题,因此我想了解一下。Skype for Business Authentication(MS RTC Authentication)返回的CWT不是CBOR Web令牌。它似乎是一种更老的技术,称为紧凑型Web票证。我不知道解析这些字符串内容的方法,但它不是作为JSON Web令牌或CBOR Web令牌。