Javascript中的REST API身份驗證

Question

我正在編寫一個基於REST的無狀態API，我計劃從幾個不同的地方使用這些API，其中一個將是單頁Javascript Web應用程序。這個想法基本上是讓一個API用於各種不同的客戶端 - 包括那些可能由其他人編寫的API，但仍然可能需要訪問用戶數據 - 而不是針對不同的客戶端使用不同的API。

我現在碰到的問題是驗證。理想情況下，我想在這裏使用標準，而不是滾動自己的標準，但我正在努力尋找適合的標準。我也試圖根據誰在打電話來避免不同驗證機制的解決方案。在這個階段，我實際上並不僅僅需要驗證實際使用應用程序的用戶身份 - 通過用戶名和密碼或類似的方式 - 但是如果/當客戶端不是網頁的客戶端想要使用它時，他們應該可能也會被認證。

從我一直在看，看起來最好的方法是使用HTTP基本身份驗證通過HTTPS連接。我忍不住想，但這是錯過了一些東西。顯而易見的替代方案似乎是OAuth 1.0 - 這要求潛在的不安全的Javascript會話知道客戶端密鑰 - 或OAuth 2.0 - 似乎要回到使用SSL上的用戶名/密碼生成訪問令牌，然後使用該訪問令牌再次通過SSL請求，這與HTTP Basic基本相同，但稍微有些混淆。

請注意，我沒有在這裏計算HTTP摘要，只是因爲 - 據我瞭解 - 傳遞給服務器的內容是包含以不可檢索形式（即散列）的密碼的東西，如果我存儲密碼在後端以不可檢索的形式以及我不能比較這兩個...

Answer 1

我會創建一個單獨的API來處理用戶登錄。您的API客戶端（JS網頁）可以通過HTTP Digest + SSL將用戶名/密碼提交給此登錄API。然後API將針對用戶存儲（數據庫或文件等）執行登錄，並返回結果 - 批准/拒絕訪問。

如果獲得批准，它應該返回一個經過身份驗證的令牌（例如，通過用戶名+密碼+角色+權限+日期時間或其他）的單向散列函數。

您的JS客戶端（通過瀏覽器）發出的所有後續請求都需要將此令牌（可能會在用戶會話對象中，或者加密cookie中）傳遞給您正在與之交互的所有API。令牌可以定時到期，之後用戶將被強制重新登錄。

這種方法保持無狀態，但有一些問題。如果登錄令牌被盜用或被用戶共享會怎麼樣？在令牌的整個生命週期中，任何擁有令牌副本的人都可以發起假裝成爲用戶的查詢（中間人）。 SSL應該防止它成爲消息的最外層信封。

我可以想像在你的REST（業務）API和REST（登錄）API之間做某種手搖。因此，當您的REST業務API收到此令牌時，可能會要求登錄API驗證它是否創建了此用戶代理。

無論如何，對於簡單的應用，上述方法應該就足夠了。