單點登入（Single Sign On）解決方案
單點登入（Single Sign On）解決方案
需求
多個應用系統中，使用者只需要登入一次就可以訪問所有相互信任的應用系統。
A 網站和 B 網站是同一家公司的關聯服務。現在要求，使用者只要在其中一個網站登入，再訪問另一個網站就會自動登入，請問怎麼實現？
涉及到的關鍵點：
這裡就涉及到了 跨域認證 以及 前端頁面 JavaScript 跨域 問題。
一、跨域認證問題
網際網路服務離不開使用者認證。一般流程是下面這樣。
- 使用者向伺服器傳送賬戶和密碼
- 伺服器驗證通過後，在當前會話 （session）裡儲存相關資料，如使用者角色、使用者ID等
- 伺服器向用戶返回一個 session_id，寫入使用者 cookie
- 使用者之後的每一次請求，都會通過 Cookie 將 session_id 傳回伺服器
- 伺服器收到 session_id ，找到之前儲存的資料，由此得知使用者身份
下面以 登入 A 站點 訪問 B 站點 為例
方案一： session 持久化
將 session 資料持久化，寫入資料庫或別的持久層。各種服務受到請求後，都向持久層請求資料。
這種方案，對於各種系統的程式碼改動量少，只要在許可權驗證的地方進行判斷即可。
-
A 登入成功程式碼
登入成功後，將 session 儲存到 Redis 持久化儲存，注意設定有效期
tip：
Redis 以層級形式、目錄形式儲存資料，最大四級，格式如下：
set('dir:dir:dir:key', 'value');
/** * 將 Session 儲存到 Redis
* @param boolean $logout 是否退出登陸 預設否
* @return array
*/
public function sessionToRedis($logout = false)
{
try {
if ($logout) {
(new Redis())->del('Admin:session:' . session_id());}else{
$userInfo = session('CH_ADMIN_LOGIN_STATUS');
$res = (new Redis())->setex('Admin:session:' . session_id(), 28800, json_encode($userInfo, JSON_UNESCAPED_UNICODE));
if ($res === false) throw new \Exception('Redis 儲存失敗');
return true;
}
} catch (\Exception $e) {
return false;
}
}
-
登入成功後 訪問 B, B 進行使用者身份認證
注意 此時 訪問 B的連結URL 要攜帶引數 sessionid！
B 在處理請求- 身份驗證時，先解析是否攜帶了sessionid引數，攜帶了則向 redis 中查詢相關資料，並將資料儲存到當前會話中。此時就成功 登入 B 了。
/** * 通過其他後臺單點登陸
* 傳遞session_id(用於session共享)
*/
$params = $request->param();
if (!empty($params) && isset($params['session_id'])) {
session_id($params['session_id']); // 設定會話id
$userInfo = Session::get('userinfo', 'admin');
if (empty($userInfo)) {
$userInfo = json_decode((new Redis())->get('Admin:session:'.$params['session_id']), true);
Session::set('userinfo', $userInfo, 'admin');
}
} else {
$userInfo = Session::get('userinfo', 'admin');
}
方案二：JWT（JSON Web Token）
伺服器索性不儲存 session 資料了，「使用者資料」加密儲存到「客戶端」，每次請求都將資料發回伺服器，伺服器再進行解析得到使用者身份資訊資料。JWT 就是這種方案的一個代表。
JWT 原理
伺服器認證後，生成一個 JSON 物件，發回給使用者，就像下面這樣。
{
"姓名": "張三",
"角色": "管理員",
"到期時間": "2019年10月1日0點0分"
}
以後，使用者與服務端通訊的時候，都要發回這個 JSON 物件。伺服器完全只靠這個物件認定使用者身份。為了防止使用者篡改資料，伺服器在生成這個物件的時候，會加上簽名（詳見後文）。
伺服器就不儲存任何 session 資料了，也就是說，伺服器變成無狀態了，從而比較容易實現擴充套件。
JWT 的資料結構
它是一個很長的字串，中間用點（.）分隔成三個部分。注意，JWT 內部是沒有換行的，這裡只是為了便於展示，將它寫成了幾行。
JWT 的三個部分依次如下。
- Header（頭部）
- Payload（負載）
- Signature（簽名）
寫成一行，就是下面的樣子。
Header.Payload.Signature
Header
Header 部分是一個 JSON 物件，描述 JWT 的元資料，通常是下面的樣子。
{
"alg": "HS256",
"typ": "JWT"
}
上面程式碼中，alg屬性表示簽名的演算法（algorithm），預設是 HMAC SHA256（寫成 HS256）；typ屬性表示這個令牌（token）的型別（type），JWT 令牌統一寫為JWT。
最後，將上面的 JSON 物件使用 Base64URL 演算法（詳見後文）轉成字串。
Payload
Payload 部分也是一個 JSON 物件，用來存放實際需要傳遞的資料。JWT 規定了7個官方欄位，供選用。
- iss (issuer)：簽發人
- exp (expiration time)：過期時間
- sub (subject)：主題
- aud (audience)：受眾
- nbf (Not Before)：生效時間
- iat (Issued At)：簽發時間
- jti (JWT ID)：編號
除了官方欄位，你還可以在這個部分定義私有欄位，下面就是一個例子。
{
"sub": "1234567890",
"name": "John Doe",
"admin": true
}
注意，JWT 預設是不加密的，任何人都可以讀到，所以不要把祕密資訊放在這個部分。
這個 JSON 物件也要使用 Base64URL 演算法轉成字串。
Signature
Signature 部分是對前兩部分的簽名，防止資料篡改。
首先，需要指定一個金鑰（secret）。這個金鑰只有伺服器才知道，不能洩露給使用者。然後，使用 Header 裡面指定的簽名演算法（預設是 HMAC SHA256），按照下面的公式產生簽名。
HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
secret)
算出簽名以後，把 Header、Payload、Signature 三個部分拼成一個字串，每個部分之間用"點"（.）分隔，就可以返回給使用者。
Base64URL
前面提到，Header 和 Payload 串型化的演算法是 Base64URL。這個演算法跟 Base64 演算法基本類似，但有一些小的不同。
JWT 作為一個令牌（token），有些場合可能會放到 URL（比如 api.example.com/?token=xxx）。Base64 有三個字元+、/和=，在 URL 裡面有特殊含義，所以要被替換掉：=被省略、+替換成-，/替換成_。這就是 Base64URL 演算法。
JWT 的使用方式
客戶端收到伺服器返回的 JWT，可以儲存在 Cookie 裡面，也可以儲存在 localStorage。
此後，客戶端每次與伺服器通訊，都要帶上這個 JWT。你可以把它放在 Cookie 裡面自動傳送，但是這樣不能跨域，所以更好的做法是放在 HTTP 請求的頭資訊Authorization欄位裡面。
Authorization: Bearer <token>
另一種做法是，跨域的時候，JWT 就放在 POST 請求的資料體裡面。
JWT 的幾個特點
（1）JWT 預設是不加密，但也是可以加密的。生成原始 Token 以後，可以用金鑰再加密一次。
（2）JWT 不加密的情況下，不能將祕密資料寫入 JWT。
（3）JWT 不僅可以用於認證，也可以用於交換資訊。有效使用 JWT，可以降低伺服器查詢資料庫的次數。
（4）JWT 的最大缺點是，由於伺服器不儲存 session 狀態，因此無法在使用過程中廢止某個 token，或者更改 token 的許可權。也就是說，一旦 JWT 簽發了，在到期之前就會始終有效，除非伺服器部署額外的邏輯。
（5）JWT 本身包含了認證資訊，一旦洩露，任何人都可以獲得該令牌的所有許可權。為了減少盜用，JWT 的有效期應該設定得比較短。對於一些比較重要的許可權，使用時應該再次對使用者進行認證。
（6）為了減少盜用，JWT 不應該使用 HTTP 協議明碼傳輸，要使用 HTTPS 協議傳輸。
二、JavaScript 跨域
單點登入難免會遇到視窗之間 JS 跨域問題，此時的解決方案是 postMessage
postMessage 是HTML5 XMLHttpRequest Level 2中的API，且是為數不多可以跨域操作的window屬性之一，它可用於解決以下方面的問題：
a.） 頁面和其開啟的新視窗的資料傳遞
b.） 多視窗之間訊息傳遞
c.） 頁面與巢狀的iframe訊息傳遞
d.） 上面三個場景的跨域資料傳遞
用法：postMessage(data,origin) 方法接受兩個引數
data： html5規範支援任意基本型別或可複製的物件，但部分瀏覽器只支援字串，所以傳參時最好用JSON.stringify()序列化。
origin： 協議+主機+埠號，也可以設定為"*"，表示可以傳遞給任意視窗，如果要指定和當前視窗同源的話設定為"/"。
1.）a.html：(http://www.domain1.com/a.html)
<iframe id="iframe" src="http://www.domain2.com/b.html" style="display:none;"></iframe>
<script>
var iframe = document.getElementById('iframe');
iframe.onload = function() {
var data = {
name: 'aym'
};
// 向domain2傳送跨域資料
iframe.contentWindow.postMessage(JSON.stringify(data), 'http://www.domain2.com');
};
// 接受domain2返回資料
window.addEventListener('message', function(e) {
alert('data from domain2 ---> ' + e.data);
}, false);
</script>
2.）b.html：(http://www.domain2.com/b.html)
<script>
// 接收domain1的資料
window.addEventListener('message', function(e) {
alert('data from domain1 ---> ' + e.data);
var data = JSON.parse(e.data);
if (data) {
data.number = 16;
// 處理後再發回domain1
window.parent.postMessage(JSON.stringify(data), 'http://www.domain1.com');
}
}, false);
</script>
更多跨域問題參考 前端常見跨域解決方案（全）
參考連結
JSON Web Token 入門教程
前端常見跨域解決方案（