Angular 經常會被用到後臺和管理工具的開發，這兩類都會需要對用戶進行鑑權。而鑑權的第一步，就是進行身份驗證。由於 Angular 是單頁應用，會在一開始，就把大部分的資源加載到瀏覽器中，所以就更需要注意驗證的時機，並保證只有通過了驗證的用戶才能看到對應的界面。
功能邊界
本篇文章中的身份驗證，指的是如何確定用戶是否已經登陸，並確保在每次與服務器的通信中，都能夠滿足服務器的驗證需求。注意，並不包括對具體是否具有某一個權限的判斷。
對於登陸，主要是接受用戶的用戶名密碼輸入，提交到服務器進行驗證，處理驗證響應，在瀏覽器端構建身份驗證數據。
實現身份驗證的兩種方式
目前，實現身份驗證的方法，主要有兩個大類：
Cookies
傳統的瀏覽器網頁，都是使用 Cookies 來驗證身份，實際上，瀏覽器端的應用層裏，基本不用去管身份驗證的事情，Cookies 的設置，由服務器端完成，在提交請求的時候，由瀏覽器自動附加對應的 Cookies 信息，所以在 JavaScript 代碼中，不需要爲此編寫專門的代碼。但每次請求的時候，都會帶上全部的 Cookies 數據，
隨着 CDN 的應用，移動端的逐漸興起， Cookies 越來越不能滿足複雜的、多域名下的身份驗證需求。
密鑰
實際上基於密鑰的身份驗證並不是最近才興起，它一直存在，甚至比 Cookies 歷史更長。當瀏覽器在請求服務器的時候，將密鑰以特定的方式附加在請求中，比如放在請求的頭部（ headers ）。爲此，需要編寫專門的客戶端代碼來管理。
最近出現的基於 JSON 的 Web 密鑰（JSON Web Token）標準，便是典型的使用密鑰來實現的身份驗證。
在 Web 應用中，如果是構造 API ，則應優先考試使用密鑰方式。
處理登陸
登陸是身份驗證第一步，通過登陸，才能夠組織起來對應的身份驗證數據。
需要使用單獨的登陸頁嗎？
登陸頁的處理，有兩種方式：
- 單獨的登陸頁，在登陸完成後，跳轉到單頁應用之中，這樣做可以對單頁應用的資源進行訪問控制，防止非登陸用戶訪問，適合後臺或者管理工具的應用場景。但實際上降低了單頁應用的用戶體驗
- 在單頁應用之內執行登陸，這樣更符合單頁應用的設計理念，比較適合大衆產品的場景，因爲惡意的人總是能夠拿到你單頁應用的前端代碼
單獨的登陸頁
一般情況下，使用單獨的登陸頁的目的在於保護登陸後跳轉的頁面不被匿名用戶訪問。因此，在登陸頁裏，構造一個表單，直接採用傳統的表彰提交方式（非 Ajax），後端驗證用戶名密碼成功後，輸出登陸後單面應用頁面的 HTML 。
在這種情況下，可以直接將身份驗證信息放在輸出的 HTML 裏，比如，可以使用 Jade 構造一個這樣的頁面：
doctype html
html
head
link(rel="stylesheet", href="/assets/app.e1c2c6ea9350869264da10de799dced1.css")
body
script.
window.token = !{JSON.stringify(token)};
div.md-padding(ui-view)
script(src="/assets/app.84b1e53df1b4b23171da.js")
後端在用戶名密碼驗證成功之後，可以採用如下的方式來渲染輸出 HTML ：
return res.render('dashboard', {
token: token
});
Angular 應用一啓動，便可以進行需要使用身份驗證的通信。而且還保證了只有登陸成功的用戶纔可以進入這個頁面。
單頁應用內登陸的組織
對於多視圖的 Angular 應用，一般會採用路由，在頁面之內，一般有固定的側邊欄菜單，或者頂部導航菜單，正文區域由路由模塊來控制。
下面的示例代碼，使用的是 Angular Material 來組織頁面，路由模塊使用的是 ui-router 。在應用打開的時候，有專門的加載動畫，加載完成之後，顯示的頁面，使用 AppController 這個控制器，對於沒有登陸的用戶，會顯示登陸表單，登陸完成之後，頁面分爲三大部分，一是頂部麪包屑導航，二是側邊欄菜單，另外就是路由控制的正文部分。代碼如下：
對於 Loading 動畫，是在 AppController 之外的，可以在 AppController 的代碼中，對其進行隱藏。這樣達到了所有 CSS / JavaScript 加載完成之後 Loading 就消失的目的。
AppController 中有一個變量 isUserAuth ，初始化的時候是 false ，當本地存儲的會話信息驗證有效，或者登陸完成之後，這個值便會置爲 ture ，由於 ng-if 的控制，便可以實現隱藏登陸表單、顯示應用內容的目的。要注意，這裏只有使用 ng-if 而不是 ng-show/ng-hide ，前者纔會真正的刪除和增加 DOM 元素，而後者只是修改某個 DOM 元素的 CSS 屬性，這點很重要，只有這樣，才能夠保證登陸完成之後，再加載單頁應用中的內容，防止還沒有登陸，當前路由中的控制器代碼就直接執行了。
爲什麼客戶端也要加密密碼
一個比較理想的基於用戶名和密碼的登陸流程是這樣的：
- 瀏覽器端獲取用戶輸入的密碼，使用 MD5 一類的哈希算法，生成固定長度的新密碼，如
md5(username + md5(md5(password)))，再將密碼哈希值和用戶名提交給後端 - 後端根據用戶名獲取對應的鹽，使用用戶名和密碼哈希值，算出一個密文，根據用戶名和密文去數據庫查詢
- 如果查詢成功，則生成密鑰，返回給瀏覽器，並執行第 4 步
- 後端生成新的鹽，根據新的鹽和瀏覽器提交的密碼哈希值，生成新的密文。在數據庫中更新鹽和密文
可能有 80% 的人無法理解爲什麼要把一個登陸做得這麼複雜。這可能要寫一篇專門的文章才解釋得清楚。在這裏先解釋一下爲什麼瀏覽器端要對密碼做哈希，原因如下：
- 從源頭上保護用戶的密碼，保證只有做按鍵記錄纔可以拿到用戶的原始密碼
- 就算網絡被竊聽，又沒有使用 https ，那麼被偷走的密碼，也只是哈希之後的，最多影響用戶在這個服務器裏的數據，而不影響使用相同密碼的其它網站
- 就算是服務器的所有者，都無法獲取用戶的原始密碼
這種做法，使得用戶的最大風險，也只是當前這個應用中的數據被竊取。不會擴大損失範圍，絕不會出現 CSDN 之流的問題。
登陸成功的通知
對於有些應用，並不是所有的頁面都需要用戶登陸的，可能是進行某些操作的時候，才需要登陸。在這種情況下，登陸完成之後，必須要通知整個應用。這可以使用廣播這個功能。
簡易代碼如下：
angular
.module('app')
.controller('LoginController', ['$rootScope', LoginController]);
function LoginController($rootScope) {
// 登陸成功之後調用的函數
function afterLoginSuccess() {
$rootScope.$broadcast('user.login.success', {
// 需要傳輸的數據
});
}
}
在其它的控制器中，便可以監聽這個廣播，並執行登陸成功之後需要進行的操作，如獲取列表或者詳情：
$scope.$on('user.login.success', function(handle, data){
});
身份驗證信息
登陸成功之後，服務器返回了密鑰，之後的 API 請求都需要帶上密鑰，而且請求返回的響應，還需要檢查是否是關於身份信息失效的錯誤。這一系列的工作比較繁瑣，應該是自動完成纔行。
保存
密鑰的保存，大概有如下幾個辦法：
- Cookies：前面已經提到了，這個並不推薦使用。同時，它還有最大 4k 的限制
- sessionStorage：tab 頁內有效，一旦關閉，或者打開了新的 tab 頁，sessionStorage 是不能共享的
- localStorage：較爲理想的存儲方式，除非清理瀏覽器數據，否則 localStorage 存儲的數據會一直存在
- Angular 單例 Service：存儲在應用之內得話，刷新後數據會丟失，當然也不能 tab 頁之間共享
比較好的辦法是，身份驗證信息存儲在 localStorage 裏，但在應用啓動時，初始化到 Angular 的單例 Service 中。
在請求中加入身份驗證信息
身份驗證信息的目的，是爲了向服務器表明身份，獲取數據。所以，在請求中需要附加身份驗證信息。
一般的應用中，身份驗證信息都是放在請求的 headers 頭部中。如果在每次請求的時候，一一設置 headers ，那就太費時費力了。Angular 中的 $httpProvider 提供了一個攔截器 interceptors ，通過它可以實現對每一個請求和響應的統一處理。添加攔截器的方式如下：
angular
.module('app')
.factory('HttpInterceptor', ['$q', HttpInterceptor]);
function HttpInterceptor($q) {
return {
// 請求發出之前，可以用於添加各種身份驗證信息
request: function(config){
if(localStorage.token) {
config.headers.token = localStorage.token;
}
return config;
},
// 請求發出時出錯
requestError: function(err){
return $q.reject(err);
},
// 成功返回了響應
response: function(res){
return res;
},
// 返回的響應出錯，包括後端返回響應時，設置了非 200 的 http 狀態碼
responseError: function(err){
return $q.reject(err);
}
};
}
攔截器提供了對發出請求到返回響應的全生命週期處理，一般可以用來做下面幾個事情：
- 統一在發出的請求中添加數據，如添加身份驗證信息
- 統一處理錯誤，包括請求發出時出的錯（如瀏覽器端的網絡不通），還有響應時返回的錯誤
- 統一處理響應，比如緩存一些數據等
- 顯示請求進度條
在上面的示例代碼中，當 localStorage 中包括 token 這個值時，就在每一個請求的頭部，添加一個 token 值。
失效及處理
一般的，後端應該在 token 驗證失敗時，將響應的 http 狀態碼設置爲 401 ，這樣，在攔截器的 responseError 中便可以統一處理：
responseError: function(err){
if(-1 === err.status) {
// 遠程服務器無響應
} else if(401 === err.status) {
// 401 錯誤一般是用於身份驗證失敗，具體要看後端對身份驗證失敗時拋出的錯誤
} else if(404 === err.status) {
// 服務器返回了 404
}
return $q.reject(err);
}
其實，只要服務器返回的狀態碼不是 200 ，都會調用 responseError ，可以在這裏，統一處理並顯示錯誤。