認證
進入移動互聯網時代，大家每天都在刷手機，常用的軟件有微信、支付寶、頭條等，下邊拿微信來舉例子說明認證 相關的基本概念，在初次使用微信前需要註冊成爲微信用戶，然後輸入賬號和密碼即可登錄微信，輸入賬號和密碼 登錄微信的過程就是認證。
系統爲什麼要認證?
認證是爲了保護系統的隱私數據與資源，用戶的身份合法方可訪問該系統的資源。
認證 : 用戶認證就是判斷一個用戶的身份是否合法的過程，用戶去訪問系統資源時系統要求驗證用戶的身份信 息，身份合法方可繼續訪問，不合法則拒絕訪問。常見的用戶身份認證方式有:用戶名密碼登錄，二維碼登錄，手 機短信登錄，指紋認證等方式。
會話
用戶認證通過後，爲了避免用戶的每次操作都進行認證可將用戶的信息保證在會話中。會話就是系統爲了保持當前用戶的登錄狀態所提供的機制，常見的有基於session方式、基於token方式等。
基於session的認證方式如下圖:
它的交互流程是，用戶認證成功後，在服務端生成用戶相關的數據保存在session(當前會話)中，發給客戶端的 sesssion_id 存放到 cookie 中，這樣用戶客戶端請求時帶上 session_id 就可以驗證服務器端是否存在 session 數 據，以此完成用戶的合法校驗，當用戶退出系統或session過期銷燬時,客戶端的session_id也就無效了。
基於token方式如下圖:
它的交互流程是，用戶認證成功後，服務端生成一個token發給客戶端，客戶端可以放到 cookie 或 localStorage等存儲中，每次請求時帶上 token，服務端收到token通過驗證後即可確認用戶身份。
基於session的認證方式由Servlet規範定製，服務端要存儲session信息需要佔用內存資源，客戶端需要支持 cookie;基於token的方式則一般不需要服務端存儲token，並且不限制客戶端的存儲方式。如今移動互聯網時代 更多類型的客戶端需要接入系統，系統多是採用前後端分離的架構進行實現，所以基於token的方式更適合。
授權
還拿微信來舉例子，微信登錄成功後用戶即可使用微信的功能，比如，發紅包、發朋友圈、添加好友等，沒有綁定 銀行卡的用戶是無法發送紅包的，綁定銀行卡的用戶纔可以發紅包，發紅包功能、發朋友圈功能都是微信的資源即 功能資源，用戶擁有發紅包功能的權限纔可以正常使用發送紅包功能，擁有發朋友圈功能的權限纔可以使用發朋友 圈功能，這個根據用戶的權限來控制用戶使用資源的過程就是授權。
認證是爲了保證用戶身份的合法性，授權則是爲了更細粒度的對隱私數據進行劃分，授權是在認證通過後發生的， 控制不同的用戶能夠訪問不同的資源。
授權: 授權是用戶認證通過根據用戶的權限來控制用戶訪問資源的過程，擁有資源的訪問權限則正常訪問，沒有權限則拒絕訪問。
授權的數據模型
如何進行授權即如何對用戶訪問資源進行控制，首先需要學習授權相關的數據模型。
授權可簡單理解爲Who對What(which)進行How操作，包括如下:
- Who，即主體(Subject)，主體一般是指用戶，也可以是程序，需要訪問系統中的資源。
- What，即資源 (Resource)，如系統菜單、頁面、按鈕、代碼方法、系統商品信息、系統訂單信息等。系統菜單、頁面、按 鈕、代碼方法都屬於系統功能資源，對於web系統每個功能資源通常對應一個URL;系統商品信息、系統訂單信息 都屬於實體資源(數據資源)，實體資源由資源類型和資源實例組成，比如商品信息爲資源類型，商品編號 爲001 的商品爲資源實例。
- How，權限/許可(Permission)，規定了用戶對資源的操作許可，權限離開資源沒有意義， 如用戶查詢權限、用戶添加權限、某個代碼方法的調用權限、編號爲001的用戶的修改權限等，通過權限可知用戶 對哪些資源都有哪些操作許可。
主體、資源、權限關係如下圖:
主體、資源、權限相關的數據模型如下:
主體(用戶id、賬號、密碼、…)
資源(資源id、資源名稱、訪問地址、…)
權限(權限id、權限標識、權限名稱、資源id、…)
角色(角色id、角色名稱、…)
角色和權限關係(角色id、權限id、…) 主體(用戶)
角色和角色關係(用戶id、角色id、…)
主體(用戶)、資源、權限關係如下圖:
通常企業開發中將資源和權限表合併爲一張權限表，如下:
資源(資源id、資源名稱、訪問地址、…)
權限(權限id、權限標識、權限名稱、資源id、…)
合併爲:
權限(權限id、權限標識、權限名稱、資源名稱、資源訪問地址、…)
修改後數據模型之間的關係如下圖:
RBAC
1. 基於角色的訪問控制
RBAC基於角色的訪問控制(Role-Based Access Control)是按角色進行授權，比如:主體的角色爲總經理可以查詢企業運營報表，查詢員工工資信息等，訪問控制流程如下:
根據上圖中的判斷邏輯，授權代碼可表示如下:
if(主體.hasRole("總經理角色id")){ 查詢工資
}
如果上圖中查詢工資所需要的角色變化爲總經理和部門經理，此時就需要修改判斷邏輯爲“判斷用戶的角色是否是 總經理或部門經理”，修改代碼如下:
if(主體.hasRole("總經理角色id") || 主體.hasRole("部門經理角色id")){ 查詢工資
}
根據上邊的例子發現，當需要修改角色的權限時就需要修改授權的相關代碼，系統可擴展性差。
2.基於資源的訪問控制
RBAC基於資源的訪問控制(Resource-Based Access Control)是按資源(或權限)進行授權，比如:用戶必須 具有查詢工資權限纔可以查詢員工工資信息等，訪問控制流程如下:
根據上圖中的判斷，授權代碼可以表示爲:
if(主體.hasPermission("查詢工資權限標識")){ 查詢工資
}
優點:系統設計時定義好查詢工資的權限標識，即使查詢工資所需要的角色變化爲總經理和部門經理也不需要修改 授權代碼，系統可擴展性強。