來自瀏覽器中Javascript的REST API身份驗證

Question

我正在編寫一個基於REST的無狀態API，我打算從幾個不同的地方使用它，其中一個將是一個單頁的Javascript webapp。 這個想法基本上是從各種不同的客戶端使用單個API - 包括可能由其他人編寫但仍可能需要訪問用戶數據的API - 而不是為不同的客戶端使用不同的API。

我目前遇到的問題是身份驗證。 理想情況下，我想在這里使用一些標准而不是自己動手，但我很難找到一些真正合適的標准。 我也試圖避免不同的身份驗證機制的解決方案取決於誰在進行呼叫。 在這個階段，我實際上不需要只是對實際使用應用程序的用戶進行身份驗證 - 通過用戶名和密碼，或者類似 - 但是如果/當不是網頁的客戶端想要使用它時，他們應該可能也是經過身份驗證的。

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

請注意，我沒有在這里計算HTTP Digest，只是因為 - 據我所知 - 傳遞給服務器的內容是包含不可檢索形式的密碼（即散列），如果我將密碼存儲在后端以不可檢索的形式，然后我無法比較兩個......

Answer 1

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

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

您的JS客戶端（通過瀏覽器）的所有后續請求都需要將此令牌（可能在用戶會話對象中攜帶，也可能在加密的cookie中）提交給您正在與之交互的所有API。 令牌可以定時到期，之后用戶將被迫重新登錄。

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

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

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