2015-07-09 157 views
1

我現在已經兩週的時間學習並構建了一個AngularJS + PHP系統,我仍在努力進行身份驗證。我一直在閱讀大量有關AngularJS的帖子,而且他們中的一個似乎沒有考慮認證的安全性方面。當我詢問AngularJS存儲在另一篇文章中的安全性時,我也有了一個有趣的迴應,並且在與tokens打交道時,與Stormpath的博客有兩個很好的鏈接,涵蓋了安全領域。AngularJS安全令牌與會話

大多數教程和有關AngularJS例子似乎是採取JWT方法,並通過HTTP headers發送該令牌到你的REST API,但鑑於該令牌存儲在Javascript這可以將其暴露於多種攻擊類型。其中之一是MITM。爲了抵禦這種類型的攻擊,解決方案是使用HttpOnly和Secure標誌設置cookie。現在令牌被傳遞給每個請求,它不會被Javascript存儲並且是安全的。但是,這在您驗證用戶身份的地方引發了問題:當您僅處理源自同一服務器的HTTP請求時,這與使用會話有什麼不同?

當檢查用戶是否已經登錄時,我們通常會檢查是否存在$_SESSION變量,比如說uid。現在基於令牌的方法,我們發送令牌HTTP headers並讀取該令牌,然後驗證它並獲取用戶信息。在AngularJS我們然後得到成功的迴應,並返回一個承諾。

會話具有被服務器處理的優點。他們創建一個會話,如果它仍然存在,它們會自動處理它的銷燬。在處理基於令牌的身份驗證時,如果用戶沒有自行銷燬,則必須使用預定的腳本來處理它的過期,刷新和銷燬。這似乎工作太多了。

+0

它可能很難找到任何關於安全性的信息,因爲角度與它有很少或根本沒有關係。你必須在你的服務和http請求中實現你的認證技術,但這不是一件有意義的事情,這只是一般的客戶端開發。 –

回答

1

使用令牌的想法是允許服務器完全無狀態。服務器只提供一個登錄服務,在成功登錄後返回一個臨時令牌,並立即忘記令牌,它不會將其存儲在任何地方(數據庫,內存)。

然後,客戶端在每個後續請求中發送令牌。令牌具有自我驗證的屬性:它包含有效性,用戶名和加密簽名。

這樣的簽名證明令牌對服務器有效,即使服務器已經完全丟棄了令牌。

這種方式服務器不必處理令牌的到期/銷燬:它可以檢查傳入令牌並驗證它們只檢查令牌(感謝簽名)。

這就是JSON Web令牌的優勢:它們允許完全無狀態的服務器不必管理認證令牌生命週期。