我們的證書是 Comodo Positive SSL。我們正在嘗試使用帶有https://github.com/firebase/php-jwt這個庫的Php 解碼從“使用 Apple Id API 簽名”提供的 JWT 。當我們運行 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，它會給我們Array ( [status] => [message] => Algorithm not allowed )
1 回答
一只萌萌小番薯
TA貢獻1795條經驗 獲得超7個贊
JWT 是一個令牌字符串，由一個點'.'字符分隔的三部分組成。
每個部分都經過Base64 編碼（未加密），因此您可以通過分別對每個部分進行 Base64 解碼來獲取每個部分的內容。由于 Base64 編碼的數據不包含點'.'字符，這使得在任何情況下都可以將其用作分隔符來連接三個部分。
三個子字符串的內容，一旦 JWT 被拆分并且每個單獨的部分經過 Base64 解碼，如下所示：
用于簽名的算法
JSON格式的信息內容
簽名
因此，為了檢索令牌帶來的信息，需要：
在點
'.'字符處拆分 JWT采取第二部分，
Base64-decode它
必須考慮的是，JWT 中包含的信息不受讀取保護，而是受到保護以防修改；因此，在不知道證書或加密密鑰的情況下能夠解碼和訪問這些信息并沒有錯。
與令牌相關的整個過程有三個參與者：
發行者：通常是一個身份驗證 API
承載者：通常是API 客戶端應用程序
消費者：通常是需要它響應的API
令牌的第三部分，簽名，是允許消費者確保令牌未被修改的元素，因此，其中包含的信息可以被信任，因為已由發行人檢查/提供.
不希望承載者能夠檢查令牌：它只是希望從驗證過程中接收它并將其提供給它想要使用的 API。它最終可以訪問內容，這意味著在應用程序的上下文中，接收它的客戶端對令牌信息的訪問不必構成漏洞。令牌必須通過受保護的通道（如 SSL / https）傳遞給客戶端（并發送回消費者），這是為了保護其他實體對令牌的訪問，而不是傳遞令牌的客戶端。
消費者和發行者通常（但不一定）只是同一應用程序的不同 API 方法。
用于簽名的算法可以是對稱或非對稱加密算法。在第一種情況下，加密密鑰必須在發行者和消費者之間共享。盡管這似乎是一個問題，但在發行者也是消費者（或至少它們在同一主機中）的情況下（一種非常常見的情況），情況并非如此。在這種情況下，“共享秘密”確實不與任何人共享。
當發行者需要將消費者（一個或多個）分開時，可以使用非對稱加密，以便發行者保留私鑰，而消費者只擁有公鑰。在這種情況下，當然也可以采用對稱加密，但“共享秘密”必須真正與不同的消費者共享，因此如果可以安全地完成和維護，則必須進行評估。
- 1 回答
- 0 關注
- 135 瀏覽
添加回答
舉報
0/150
提交
取消