我們的證書是 Comodo Positive SSL。我們正在嘗試使用帶有https://github.com/firebase/php-jwt這個(gè)庫的Php 解碼從“使用 Apple Id API 簽名”提供的 JWT 。當(dāng)我們運(yùn)行 decode 它給了我們A PHP Error was encounteredSeverity: WarningMessage: openssl_verify(): supplied key param cannot be coerced into a public keyFilename: php-jwt/JWT.phpLine Number: 231Array ( [status] => [message] => OpenSSL error: error:0906D06C:PEM routines:PEM_read_bio:no start line )我們不知道該怎么做.. 如果我們將 RS256 更改為 HS256，它會(huì)給我們Array ( [status] => [message] => Algorithm not allowed )
1 回答
一只萌萌小番薯
TA貢獻(xiàn)1795條經(jīng)驗(yàn) 獲得超7個(gè)贊
JWT 是一個(gè)令牌字符串，由一個(gè)點(diǎn)'.'字符分隔的三部分組成。
每個(gè)部分都經(jīng)過Base64 編碼（未加密），因此您可以通過分別對(duì)每個(gè)部分進(jìn)行 Base64 解碼來獲取每個(gè)部分的內(nèi)容。由于 Base64 編碼的數(shù)據(jù)不包含點(diǎn)'.'字符，這使得在任何情況下都可以將其用作分隔符來連接三個(gè)部分。
三個(gè)子字符串的內(nèi)容，一旦 JWT 被拆分并且每個(gè)單獨(dú)的部分經(jīng)過 Base64 解碼，如下所示：
用于簽名的算法
JSON格式的信息內(nèi)容
簽名
因此，為了檢索令牌帶來的信息，需要：
在點(diǎn)
'.'字符處拆分 JWT采取第二部分，
Base64-decode它
必須考慮的是，JWT 中包含的信息不受讀取保護(hù)，而是受到保護(hù)以防修改；因此，在不知道證書或加密密鑰的情況下能夠解碼和訪問這些信息并沒有錯(cuò)。
與令牌相關(guān)的整個(gè)過程有三個(gè)參與者：
發(fā)行者：通常是一個(gè)身份驗(yàn)證 API
承載者：通常是API 客戶端應(yīng)用程序
消費(fèi)者：通常是需要它響應(yīng)的API
令牌的第三部分，簽名，是允許消費(fèi)者確保令牌未被修改的元素，因此，其中包含的信息可以被信任，因?yàn)橐延砂l(fā)行人檢查/提供.
不希望承載者能夠檢查令牌：它只是希望從驗(yàn)證過程中接收它并將其提供給它想要使用的 API。它最終可以訪問內(nèi)容，這意味著在應(yīng)用程序的上下文中，接收它的客戶端對(duì)令牌信息的訪問不必構(gòu)成漏洞。令牌必須通過受保護(hù)的通道（如 SSL / https）傳遞給客戶端（并發(fā)送回消費(fèi)者），這是為了保護(hù)其他實(shí)體對(duì)令牌的訪問，而不是傳遞令牌的客戶端。
消費(fèi)者和發(fā)行者通常（但不一定）只是同一應(yīng)用程序的不同 API 方法。
用于簽名的算法可以是對(duì)稱或非對(duì)稱加密算法。在第一種情況下，加密密鑰必須在發(fā)行者和消費(fèi)者之間共享。盡管這似乎是一個(gè)問題，但在發(fā)行者也是消費(fèi)者（或至少它們?cè)谕恢鳈C(jī)中）的情況下（一種非常常見的情況），情況并非如此。在這種情況下，“共享秘密”確實(shí)不與任何人共享。
當(dāng)發(fā)行者需要將消費(fèi)者（一個(gè)或多個(gè)）分開時(shí)，可以使用非對(duì)稱加密，以便發(fā)行者保留私鑰，而消費(fèi)者只擁有公鑰。在這種情況下，當(dāng)然也可以采用對(duì)稱加密，但“共享秘密”必須真正與不同的消費(fèi)者共享，因此如果可以安全地完成和維護(hù)，則必須進(jìn)行評(píng)估。
- 1 回答
- 0 關(guān)注
- 169 瀏覽
添加回答
舉報(bào)
0/150
提交
取消