812 VIEWS
Pinterest LinkedIn LINE

JSON 簽名的標準化稱為 JSON Web 簽名，由 IETF 的 JOSE 工作小組 [1] 啟動。

初步草案

　

之所以提到我的名字，是因為我將 OpenID 基金會 AB/C 工作小組正在考慮的一些內容提交給了 IETF [2]。

@ritou 說：「OAuth 2.0時代的簽名請求是什麼？”，但在 Facebook 上 簽名請求 非常類似

最大的差別是signed_request是

簽名 。

相比之下，在 JWS 中，

header.body.signature

已經成為了。這是有原因的。

為什麼是「標頭.正文.簽名」？

有些人可能會說，最好讓它與世界冠軍 Facebook 一樣，但它變成這樣是有邏輯原因的。

為什麼標題要分開？

對於signed_request，簽章參數包含在主體中。如果你想加密正文，則不能採用這種方法。這是因為即使是用於解密的參數也是加密的。因此，有必要將這些與加密相關的參數單獨放在頭部部分。

我們正在努力使 JWS 和 JWE 盡可能通用。所以我必須分開標題。

為什麼簽名在最後？

另一個很大的視覺差異是，在signed_request中，簽名是第一個，而在JWS中，簽名是最後一個。 JWS 將簽章放在末端以串流簽章建立。這是因為，如果您嘗試先添加簽名，則必須緩衝所有數據，直到簽名過程完成，然後像“Signature.Body”一樣將其發送出去，如果這樣做，您可以發送越來越多的數據。 ，因此不需要緩衝所有數據，並且對伺服器資源來說是「容易」的。如果像signed_request這樣只簽署一小段數據並沒有太大區別，但JWS也可以簽署大量數據，所以考慮到了這一點。

共同特徵

singed_request、JWS也有一些共同的特徵。典型的有

  • 沒有數據標準化
  • 使用base64url進行序列化
  • 使用 JSON 作為資料格式
  • 任何資料都可以簽名

沒有數據標準化

有一個稱為 XML 數位簽章的標準。非常通用和靈活。然而，由於不同實作之間缺乏相容性，它受到了許多開發人員的不喜歡。最大的原因似乎是 XML 資料的規範化。 signed_request 和 JWS 都沒有做任何規範化來避免這個問題。按原樣使用原始資料。

使用base64url進行序列化

常常有人問我為什麼要用base64url而不是base64。答案是，base64 包含非 Web 安全的字符，例如“=”。 JWS 可以放置在 HTTP 標頭中或 GET 和 POST 參數中。與其轉義每個“=”，不如不要使用“=”填充。

使用 JSON 作為資料格式

之所以使用JSON而不是XML，是因為JSON更緊湊，具有更好的處理效能，最重要的是更受開發者歡迎。

任何資料都可以簽名

儘管這是一種對 JSON 進行簽署的方法，但您只需輸入 base64url 編碼資料作為 JSON 參數之一即可對任何資料進行簽署。

誰使用 JWS？

我希望你明白為什麼會有這樣的差異。然而，您可能會想，“如果我不使用 Facebook，那還有什麼意義呢？”我想回答如下。

首先，Facebook 並不是決定不使用它。他們對目前的signed_request 感到滿意，只是覺得不需要為此目的使用JWS。它可以用於其他目的。另外，如果 JWS 從長遠來看變得更加普遍，也許 Facebook 可以提供額外的支持，因為它更「開發者友善」？

而且，即使 Facebook 不使用它，許多玩家也會使用它。目前，這些公司包括 Microsoft、Google、Salesforce、AOL 和 eBay。

我該什麼時候回覆？

我認為JWS比較複雜。事實上，Google 和 eBay 等公司已經實施了它。所以，我認為你現在就可以開始關注，只要你不介意一些改變。如果您有簽名需求，請考慮使用JWS。

[1] 同時，一種名為 JSON Web Encryption 的加密標準已經開始。

[2] 我們決定在 IETF 上進行標準化，因為它不僅可以用於 OpenID Connect 等身分標準，還可以用於一般用途。 JSON Web Token 和 Simple Web Discovery 也是以相同方式引入的規格。

[3] 同時，JWE即將接受一次小手術。具體來說，使用CBC模式時必須加入完整性檢查。所以直到下一個草案