SSO單點登錄
準備：
- 認證中心提供GET的登錄接口給子應用
- 每個子系統對應一個secret，註冊到認證中心（可以理解成Oauth的授權碼）
- token存在本地，不支持cookie可用localstorage
子應用登錄步驟：
- 子應用攜帶secret請求認證中心登錄接口驗證是否登錄
- 如果未登錄，則跳轉到認證中心登錄界面，並通過refer攜帶當前頁面url，登錄成功後認證中心根據用戶信息生成token存入redis，之後攜帶token重定向到refer的頁面；如果登錄了，則直接攜帶token重定向到refer的界面
- 當前子系統通過規定的解密規則解析token去redis的session中獲得相關用戶登錄的信息，如果token不合法則解密失敗無法訪問
- 正常業務邏輯
如果secret和token解密規則都泄漏，則系統不安全
Oauth認證
- 應用請求用戶授權
- 用戶同意授權則將應用的回調URL轉發給認證服務器
- 認證服務器攜帶授權碼請求應用的回調URL
- 應用保存授權碼
- 請求資源時，並使用授權碼申請動態token（token有效期，應用自己維護，一般比真實有效期短一些）
- 攜帶token請求資源
HTTPS
由於非對稱加密速度慢，對稱加密速度快，所以傳輸堆成加密密鑰使用非對稱加密，之後傳輸數據使用堆成加密，步驟如下
- 客戶端請求服務端
- 服務端返回證書信息和公鑰
- 客戶端認證證書是否有效
- 認證通過後，客戶端生成對稱密鑰並存儲，用服務端提供的公鑰加密後發送給服務端
- 服務端使用私鑰解密後存儲客戶端生成的對稱密鑰
- 之後傳送數據雙方都用對稱密鑰進行加密和解密
其中4-5非對稱加密，6爲對稱加密
正向代理和反向代理
核心：正向代理隱藏客戶端、反向代理隱藏服務端
正向代理：我們要訪問某些網站，這些網站只允許指定對服務器訪問，所以我們請求某一臺指定對服務器作爲代理服務器，代理服務器代替我們請求，真正要訪問對網站認爲是代理服務器請求，隱藏了我們（客戶端）
反向代理：我們要請求php，通過nginx進行轉發給fpm，fpm處理完之後返回給nginx，nginx再將請求返回給我們，而我們請求方（客戶端）只知道我們訪問的是nginx，至於nginx又轉發給誰處理的，我們不知道，隱藏了fpm（服務端）