⑴ 一個app項目單點登錄，前端要做什麼，後端要做什麼。
前端需要做你那個用戶姓名，密碼一些驗證什麼的，然逗橡野後有山喊前如春端打包數據到後再去處理，進行
邏輯判斷
就可以了。
⑵ 請問js如何設置單點登錄
你可以將原系統的賬號密碼做成一個配置的json文件，
然後前端去訪問這個文件，賬號密碼一一對應就可以了。
從第三方系統單點登錄到目標系統，
第三方系統會發送token進行驗證，通過解析token，
獲取相應的用戶信息的json串，將其set到自己系統的session中。
⑶ 一個app項目單點登錄，前端要做什麼，後端要做什麼。
前端需要做你那個用戶姓名，密碼一些驗證什麼的，然後有前端打包數據到後再去處理，進行邏輯判斷就可以了。
⑷ 前端單點登錄如何實現
單點登錄的思路是這樣的，假定有個兩個系統，A系統登錄一次後，再訪問B系統時是不需要登錄的，當訪問B系統時，就去登錄系統判斷是否有效，如果登錄系統放行了，說明是已經登錄過的。所以，需要建一個登錄系統，從登錄系統引出是否登錄的判斷，那麼不管是哪個系統在訪問需要驗證是否登錄的時候都去驗證登錄系統。
⑸ 前端登陸實現
四種方式
Cookie 出現的原因： HTTP 協議是無狀態的，每次請求都會建立一個新的鏈接，請求結束就會斷開鏈接，優點就是可以節省鏈接資源，缺點就是無法保存用戶狀態。Cookie 的出現就是為了解決這個問題。
Cookie 是存儲在瀏覽器中的，可以通過 Js 和 set-cookie 這個響應欄位來進行設置。
cookie 的限制：
有了 cookie 之後，服務端就可以從客戶端獲取到信息，如果需要對信息進行驗證，那麼還需要 session
服務端在收到客戶端的請求之後，會在伺服器中開辟一片內存空間來存放 session
第一次登陸之後，下次再訪問的時候就會攜帶這個 cookie，服務端就可以根據 sessionId 進行驗證用戶是否登陸（判斷這個 sessionId 和服務端保存的 sessionId 是否一致，是否有這個 sessionId 的記錄或者記錄是否有效）
客戶端瀏覽器訪問伺服器的時候，伺服器把客戶端信息以某種形式記錄在伺服器上。這就是 Session。客戶端瀏覽器再次訪問時只需要從該 Session 中查找該客戶的狀態就可以了。
Token 是 伺服器 生成的一個字元串，作為客戶端請求的一個令牌。第一次登陸之後，伺服器會生成一個 Token 返回給客戶端，客戶端後續訪問的時候，只需帶上這個 Token 進行身份認證
缺點
JWT（Json Web Token）
服務端不需要存儲 Token 那麼服務端是怎麼驗證客戶端傳遞過來的 Token 是否有效的呢？
答案：
Token 並不是雜亂無章的字元串，而是通過多種演算法拼接而成的字元串
header 部分指定了這個 Token 所使用的簽名演算法
payload 部分表明了這個 JWT 的意圖
signature 部分為 JWT 的簽名，主要是為了讓 JWT 不被隨意的篡改
簽名的部分有兩個步驟
一：
二:
最後的 Token 計算如下：
單點登陸指的是公司會搭建一個公共的認證中心，公司里的所有產品的認證都可以在這個認證中心中完成，一個產品在認證中心認證之後，再去訪問其他產品時就不需要再次認證
這個時候，由於 a.com 存在已登錄的 Cookie 信息，所以伺服器端直接認證成功。
這個時候由於認證中心存在之前登陸過的 cookie，所以不需要再輸入賬號密碼，直接從第四步開始執行
目前我們已經完成了單點登錄，在同一套認證中心的管理下，多個產品可以共享登錄態。現在我們需要考慮退出了，即：在一個產品中退出了登錄，怎麼讓其他的產品也都退出登錄？
原理也不難，其實就是在攜帶 ticket 去請求認證中心的時候，再去請求一下認證中心的退出登陸的 api 即可
當某個產品 c.com 退出登陸時
sso 就是一個集中地驗證系統。你項目內請求時，向 sso 發一個請求，他給你個 token 你扔到游覽器緩存里，請求的時候放在請求頭里帶著。和其他驗證介面一樣。 他好就好在，一個賬號在不同系統里都可以登錄，因為不同項目可以共用這個 token。並且通過 sso 集中管理一些用戶信息，你可以方便的拿用戶信息。
以微信為例子
⑹ ant design pro對接SSO單點登錄
公司的SSO採用CAS機制，機制說明： https://www.jianshu.com/p/083c0597e7e0
ant design pro接入SSO時，也冊晌宏踩了一些坑
一謹仔、應用服務端
服務端使用了spring boot，spring boot跟CAS的整合可以參考文檔： https://blog.csdn.net/jw314947712/article/details/54236216
二、前端
這里有幾個坑需要注意：
1、ajax請求返回SSO登錄頁面，需要修改跳轉模式為手動跳轉。
2、由於SSO域名與前端域名不同，ajax請求結果並不會出現302返回碼。
修改utils下面的request.js文件，設置跳轉模式為手動跳轉
然後在response裡面攔州冊截
⑺ 鑒權必須了解的 5 個兄弟：cookie、session、token、jwt、單點登錄
本文你將看到：
**「前端存儲」**這就涉及到一發、一存、一帶，發好辦，登陸介面直接返回給前端，存儲就需要前端想辦法了。
前端的存儲方式有很多。
有，cookie。cookie 也是前端存儲的一種，但相比於 localStorage 等其他方式，藉助 HTTP 頭、瀏覽器能力，cookie 可以做到前端無感知。一般過程是這樣的：
「配置：Domain / Path」
cookie 是要限制::「空間范圍」::的，通過 Domain（域）/ Path（路徑）兩級。
「配置：Expires / Max-Age」
cookie 還可以限制::「時間范圍」::，通過 Expires、Max-Age 中的一種。
「配置：Secure / HttpOnly」
cookie 可以限制::「使用方式」::。
**「HTTP 頭對 cookie 的讀寫」**回過頭來，HTTP 是如何寫入和傳遞 cookie 及其配置的呢？HTTP 返回的一個 Set-Cookie 頭用於向瀏覽器寫入「一條（且只能是一條）」cookie，格式為 cookie 鍵值 + 配置鍵值。例如：
那我想一次多 set 幾個 cookie 怎麼辦？多給幾個 Set-Cookie 頭（一次 HTTP 請求中允許重復）
HTTP 請求的 Cookie 頭用於瀏覽器把符合當前「空間、時間、使用方式」配置的所有 cookie 一並發給服務端。因為由瀏覽器做了篩選判斷，就不需要歸還配置內容了，只要發送鍵值就可以。
**「前端對 cookie 的讀寫」**前端可以自己創建 cookie，如果服務端創建的 cookie 沒加HttpOnly，那恭喜你也可以修改他給的 cookie。調用document.cookie可以創建、修改 cookie，和 HTTP 一樣，一次document.cookie能且只能操作一個 cookie。
調用document.cookie也可以讀到 cookie，也和 HTTP 一樣，能讀到所有的非HttpOnly cookie。
現在回想下，你刷卡的時候發生了什麼？
這種操作，在前後端鑒權系統中，叫 session。典型的 session 登陸/驗證流程：
**「Session 的存儲方式」**顯然，服務端只是給 cookie 一個 sessionId，而 session 的具體內容（可能包含用戶信息、session 狀態等），要自己存一下。存儲的方式有幾種：
「Session 的過期和銷毀」**很簡單，只要把存儲的 session 數據銷毀就可以。****「Session 的分布式問題」**通常服務端是集群，而用戶請求過來會走一次負載均衡，不一定打到哪台機器上。那一旦用戶後續介面請求到的機器和他登錄請求的機器不一致，或者登錄請求的機器宕機了，session 不就失效了嗎？這個問題現在有幾種解決方式。
但通常還是採用第一種方式，因為第二種相當於閹割了負載均衡，且仍沒有解決「用戶請求的機器宕機」的問題。**「node.js 下的 session 處理」**前面的圖很清楚了，服務端要實現對 cookie 和 session 的存取，實現起來要做的事還是很多的。在npm中，已經有封裝好的中間件，比如 express-session - npm，用法就不貼了。這是它種的 cookie：
express-session - npm 主要實現了：
session 的維護給服務端造成很大困擾，我們必須找地方存放它，又要考慮分布式的問題，甚至要單獨為了它啟用一套 Redis 集群。有沒有更好的辦法？
回過頭來想想，一個登錄場景，也不必往 session 存太多東西，那為什麼不直接打包到 cookie 中呢？這樣服務端不用存了，每次只要核驗 cookie 帶的「證件」有效性就可以了，也可以攜帶一些輕量的信息。這種方式通常被叫做 token。
token 的流程是這樣的：
**「客戶端 token 的存儲方式」 在前面 cookie 說過，cookie 並不是客戶端存儲憑證的唯一方式。token 因為它的「無狀態性」，有效期、使用限制都包在 token 內容里，對 cookie 的管理能力依賴較小，客戶端存起來就顯得更自由。但 web 應用的主流方式仍是放在 cookie 里，畢竟少操心。 「token 的過期」**那我們如何控制 token 的有效期呢？很簡單，把「過期時間」和數據一起塞進去，驗證時判斷就好。
編碼的方式豐儉由人。**「base64」**比如 node 端的 cookie-session - npm 庫
默認配置下，當我給他一個 userid，他會存成這樣：
這里的 eyJ1c2VyaWQiOiJhIn0=，就是 {"userid":"abb」} 的 base64 而已。 「防篡改」
是的。所以看情況，如果 token 涉及到敏感許可權，就要想辦法避免 token 被篡改。解決方案就是給 token 加簽名，來識別 token 是否被篡改過。例如在 cookie-session - npm 庫中，增加兩項配置：
這樣會多種一個 .sig cookie，裡面的值就是 {"userid":"abb」} 和 iAmSecret通過加密演算法計算出來的，常見的比如HMACSHA256 類 (System.Security.Cryptography) | Microsoft Docs。
好了，現在 cdd 雖然能偽造出eyJ1c2VyaWQiOiJhIn0=，但偽造不出 sig 的內容，因為他不知道 secret。**「JWT」**但上面的做法額外增加了 cookie 數量，數據本身也沒有規范的格式，所以 JSON Web Token Introction - jwt.io 橫空出世了。
它是一種成熟的 token 字元串生成方案，包含了我們前面提到的數據、簽名。不如直接看一下一個 JWT token 長什麼樣：
這串東西是怎麼生成的呢？看圖：
類型、加密演算法的選項，以及 JWT 標准數據欄位，可以參考 RFC 7519 - JSON Web Token (JWT)node 上同樣有相關的庫實現：express-jwt - npm koa-jwt - npm
token，作為許可權守護者，最重要的就是「安全」。業務介面用來鑒權的 token，我們稱之為 access token。越是許可權敏感的業務，我們越希望 access token 有效期足夠短，以避免被盜用。但過短的有效期會造成 access token 經常過期，過期後怎麼辦呢？一種辦法是，讓用戶重新登錄獲取新 token，顯然不夠友好，要知道有的 access token 過期時間可能只有幾分鍾。另外一種辦法是，再來一個 token，一個專門生成 access token 的 token，我們稱為 refresh token。
有了 refresh token 後，幾種情況的請求流程變成這樣：
如果 refresh token 也過期了，就只能重新登錄了。
session 和 token 都是邊界很模糊的概念，就像前面說的，refresh token 也可能以 session 的形式組織維護。狹義上，我們通常認為 session 是「種在 cookie 上、數據存在服務端」的認證方案，token 是「客戶端存哪都行、數據存在 token 里」的認證方案。對 session 和 token 的對比本質上是「客戶端存 cookie / 存別地兒」、「服務端存數據 / 不存數據」的對比。**「客戶端存 cookie / 存別地兒」**存 cookie 固然方便不操心，但問題也很明顯：
存別的地方，可以解決沒有 cookie 的場景；通過參數等方式手動帶，可以避免 CSRF 攻擊。 「服務端存數據 / 不存數據」
前面我們已經知道了，在同域下的客戶端/服務端認證系統中，通過客戶端攜帶憑證，維持一段時間內的登錄狀態。但當我們業務線越來越多，就會有更多業務系統分散到不同域名下，就需要「一次登錄，全線通用」的能力，叫做「單點登錄」。
簡單的，如果業務系統都在同一主域名下，比如wenku..com tieba..com，就好辦了。可以直接把 cookie domain 設置為主域名 .com，網路也就是這么乾的。
比如滴滴這么潮的公司，同時擁有didichuxing.com xiaojukeji.com didiglobal.com等域名，種 cookie 是完全繞不開的。這要能實現「一次登錄，全線通用」，才是真正的單點登錄。這種場景下，我們需要獨立的認證服務，通常被稱為 SSO。 「一次「從 A 系統引發登錄，到 B 系統不用登錄」的完整流程」
**「完整版本：考慮瀏覽器的場景」**上面的過程看起來沒問題，實際上很多 APP 等端上這樣就夠了。但在瀏覽器下不見得好用。看這里：
對瀏覽器來說，SSO 域下返回的數據要怎麼存，才能在訪問 A 的時候帶上？瀏覽器對跨域有嚴格限制，cookie、localStorage 等方式都是有域限制的。這就需要也只能由 A 提供 A 域下存儲憑證的能力。一般我們是這么做的：
圖中我們通過顏色把瀏覽器當前所處的域名標記出來。注意圖中灰底文字說明部分的變化。
謝謝大家哦
⑻ 「浙里辦「項目單點登錄、埋點、二次回退的問題
大家可以看一看語雀 《「浙里辦」h5微應用接入流程》森野 這篇文檔。
接下來我將針對大多數人以及我個人遇到的一些問題做本篇文章的核心講解：
1.單點登錄，首先分為個人用戶的單點登錄和法人用戶的單點登錄：
個人單點登錄分為app登錄和支付寶小程序登錄：
首先我們要判斷當前環境是app環境還是支付寶小程序環境，然後跳轉到不同的路徑，個人用戶登錄我們採用的是直接跳轉到前端頁面，登錄成功後會攜帶ticket等參數跳轉到我們提供的路徑，
法人的單點登錄（app和小程序是一樣的）：
由於法人登錄跳轉到頁面時，用的是post請求訪問，但是web頁面只能通過get訪問，所以法人登錄我們採用的方法是將提供的跳轉路徑為後台服務地址，後台服務將登錄成功後通過get方式重定向到前端頁面並攜帶前端需要的參數，
2.二次回退的問題：
我發現大多數人都遇到了二次回退的問題，有很多人解決了二次回退的問題後又出現了其它各種奇奇怪怪的問題，以下是我們解決這個問題的辦法：
window.performance.navigation.type 包含三個值：
0 : TYPE_NAVIGATE (用戶通過常規導航方式訪問頁面，比如點一個鏈接，或者一般的get方式)
1 : TYPE_RELOAD (用戶通過刷新，包括JS調用刷新介面等方式訪問頁面)
2 : TYPE_BACK_FORWARD (用戶通過後退按鈕訪問本頁面)
首先還是判斷是浙里辦app還是支付寶小程物春早序,根據不同的環境處理二次回退
解決app的二次回退問題，這個地方的邏輯是監聽頁面的跳轉,判斷當前頁面是通過刷新或直接訪問進入，還是通過返回進入。從而來判斷是否是直接跳回app
解決支付寶小程序的二次回退問題，這個地方的邏輯是監聽頁面的跳轉,判斷當前頁面是通過刷新或直接訪問進入，還是通過返回進入。從而來判斷是否是直罩雀接跳回浙里辦小程序頁面。
3.埋點，由於有些埋點是通過JSBridge API 獲取的，而JSBridge API 的方法都是非同步的，所以可能會存在埋點不成功的問題。：
埋點主要是採集應用app的信息,日誌，用戶信息和地理位置等信息
web 端通用採集 SDK： https://d.alicdn.com/alilog/mlog/aplus.js?id=202951085
使用vue開發的，這一段要寫在埋點頁面的script裡面，盡量不要放在vue實例中，也不要放在index.html中，否則可能會存在埋點不成功的問題
⑼ 單點登錄的幾種實現方案
用戶已經登錄企業門戶的前提下，單點登錄到門戶中的應用。門戶與應用的域名有一定關系，門戶的域名是父級域，比如xxx.com，應用的域名為二級域，比如a.xxx.com、b.xxx.com、c.xxx.com
登錄掘敬門戶後埋扒，頒發一個token用於介面認判液慎證，創建一個key為_a，domain為.xxx.com，path為/，value為token的cookie並set-cookie到前端，訪問其他應用時，由於_a的domain為其他應用域名的父級域，會自動帶上_a到後端，後端根據_a做介面校驗，獲取用戶信息等資源，實現單點登錄。
用戶已經登錄企業門戶的前提下，單點登錄到門戶中的應用。門戶與應用的域名沒有關系。
依舊使用上面的方案一，但是token使用header傳輸，不存在跨域問題
以上方案二，有一些細節需要注意
沒有門戶，或者用戶不提前登錄門戶的前提下，不同應用實現單點登錄。
CAS，網上教程眾多，比如 CAS簡介和整體流程 。
方案二實際上也是利用了CAS思想實現的，ticket和token，可以類比CAS的ST（Service Ticket）和TGC（Ticket Granted Cookie）。
⑽ CAS搭建單點登錄Web端
①前端vue項目判斷如果有token,則說明用戶已登錄，可以訪問客戶端A的服務。否則未登陸，未登陸有兩種狀態：在單點登錄服務端已經登錄和未在單點登錄服務端登陸
判斷如果有ticket，則說明已在單點登錄服務端登錄。調用/cas/client/validateLogin介面驗證該ticket是否有效。轉②
判斷如果無ticket,則說明未在單點登錄服務端登錄。則定向到單點登錄服務端。轉③
②/cas/client/validateLogin介面方法，發起http請求到單點登錄服務端進行ticket驗證，如果驗證通過，則登錄成功。單點登錄客戶端A生成token返回給前端，之後前端通過攜帶token訪問客戶端A的服務。
③單點登錄服務端返回登錄表單，用戶輸入用戶名密碼確定登錄後，單點登錄服務端調用用戶信息驗證端/auth/user/login介面，傳遞用戶名密碼參數，將驗證委託給用戶信息驗證端
④登錄成功驗證通過後，攜帶ticket返回瀏覽器，重定向地址如下:
http://localhost:8000/?ticket=ST-6-NqvtyjRhezstXiyyzNNN-C-DiTw-DESKTOP-CVVQ0QK
接入用戶信息驗證端參考