單點登陸（Single Sign On）解決方案

需求

多個應用系統中，用戶只須要登陸一次就能夠訪問全部相互信任的應用系統。

A 網站和 B 網站是同一家公司的關聯服務。如今要求，用戶只要在其中一個網站登陸，再訪問另外一個網站就會自動登陸，請問怎麼實現？

涉及到的關鍵點：

這裏就涉及到了 跨域認證 以及 前端頁面 JavaScript 跨域 問題。

1、跨域認證問題

互聯網服務離不開用戶認證。通常流程是下面這樣。

• 用戶向服務器發送帳戶和密碼
• 服務器驗證經過後，在當前會話 （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 協議傳輸。

2、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>