⑴ php單點登錄怎麼實現
一般兩種方案：
1 共享SESSION（db,nosql等)
2 通過介面對每個域名下寫cookie（常見ucenter)。
至於那些在頁面上做處理，不現實的。一則涉及面廣，二則維護不方便，也不符合業務封裝（模塊化）的架構思維。
⑵ 詳解PHP如何實現單點登錄
可以配合session和資料庫(或緩存如redis或memcache)實現，具體步驟如下：
在登錄成功後保存一個時間戳+隨機字元的值，這個值暫時叫sign。把這個值存入資料庫（緩存），同時也存入session中。
寫一個函數，功能如下：讀取資料庫（緩存）中的sign，跟session中的sign對比。如不一致，則注銷當前session並提示：當前用戶已在其他地方登錄，你被頂下線。這個函數放到「鉤子」裡面，實現在每一個操作步驟之前都先調用此函數。
這樣，一個簡單的單點登錄功能就實現了。原理其實很簡單，就是每次登錄都把資料庫（緩存）裡面的sign都覆蓋一遍，這樣當之前登錄的人檢測到這個sign不一致以後就強制下線。
⑶ java系統和php系統整合，如何實現單點登陸
1、直接網上找一個單點登錄系統，把這2個系統整合到一起，
2、自己寫一個單點登錄系統，藉助中間表，比如你以java系統為主，在java系統裡面嵌入了php系統，當點擊php系統的欄目時就先去中間表check一下，然後直接跳到你的php系統上面就好，
3、如果沒有許可權啥的，你就直接放一個連接傳用戶名和密碼直接登錄訪問也行。
⑷ php 怎麼實現單點登錄
php 單點登錄並不復雜。單獨登錄 (SSO)其實就是讓用戶通過一次登錄訪問授權的網路資源。如果是要實現的話，就需要找專業的解決方案了，比如玉符SSO單點登錄解決方案。
玉符單點登錄的優勢主要有：
玉符SSO支持市面上所有標准協議，雲服務或者本地部署都搞得定，微軟的SAML、谷歌的OIDC，包括CAS、Oauth、JWT等待各種協議都支持
可以提供自研SDK，完美解決自研系統或者沒有標准介面應用的問題，只需要十幾行代碼就可以完成。
玉符單點登錄SSO已經實現產品化，交付迅速，時間短，安全性強，單點登錄全部通過token令牌實現，不會拿到用戶的密碼，安全可靠。
希望我的回答對你有幫助。
⑸ 談談單點登錄
寒假學習的小課題，把之前的筆記整理整理記錄一下（長文警告）因為當時看到的東西涉及很多，所以有一些地方沒有深入去探討。
網路：單點登錄（Single Sign On），簡稱為 SSO，是目前比較流行的企業業務整合的解決方案之一。SSO的定義是在多個應用系統中，用戶只需要登錄一次就可以訪問所有相互信任的應用系統。
簡而言之就是用戶在多個相互信任的應用系統中，只需要登錄一次，就可以訪問其他相互信任的應用系統。這里的關鍵是一次登錄，以及一次退出，都對所有的系統生效。
在普通的登錄中，比如典型的B/S情景，瀏覽器訪問伺服器，發送登錄請求，在發送完用戶名和密碼之後，伺服器會生成該用戶的session來標准該用戶的狀態，比如已登錄還是已注銷，並給一個cookie給瀏覽器，因此，用戶繼續訪問就會帶上這個cookies，服務端會根據這個Cookie找到對應的session，通過session來判斷這個用戶的登錄狀態。比如php中使用phpsessid。當然也可以自定義session的生命周期，session的生命周期過長的話一旦session被盜用就會出現用戶被竊取的情況。同時，生命周期過長的session配置會佔用較多的伺服器資源。
單點登錄主要針對同平台下多應用，多系統的情景下多次登錄的一種解決方案。單點登錄相當於將多個應用的認證體系聯通。
假設現在一個平台上有3個都帶有登錄功能的應用，由上面的普通登錄的情況可以想到，這3台伺服器都會自己的記錄session。那麼要想達到單點登錄，一個最簡單的方法就出現了：共享session。
共享session的方式來實現單點登錄是最方便也是最直接的。在三個子系統中，使用同一個額外的記錄session的伺服器，比如我們可以使用一個redis伺服器來存儲三個系統的session。
用戶登錄了應用1，獲取了應用1返回的cookies，再次訪問應用1的其他功能的候攜帶了cookie就是已登錄的狀態了，但是這樣又有新的問題，雖然實現了共享session，但是用戶登錄了應用1，獲取了應用1返回的cookie，但是因為cookie是無法跨域的，因此用戶無法使用應用1的cookie去訪問應用2。這里我們就需要將系統的全局cookie domain的屬性設置為頂級域名，比如應用1的域名是1.test.com，應用2的域名是2.test.com。在普通登錄的情況下，應用1的cookie domain的屬性是1.test.com，指這個cookie只能在該子域名上被使用。我們將系統的全局cookie domain設置為頂級域名，即.test.com，這樣就可以實現用戶登錄了應用1，之後可以以已登錄狀態訪問應用2和3。
上面的共享session的情況是三個應用都有登錄功能，還有一種類似的情況是應用1和應用2都有登錄模塊和其他模塊，還有一個單獨的SSO系統，是僅有登錄模塊的：
共享session的方法雖然簡單，但是存在局限性，因為使用了cookie頂域的特性，所以不能做到跨域。一個公司或者一個平台很可能不是所有的域名都在在一個一級域名之下的，所以同域名下的單點登錄並不是完整的單點登錄。
先說說openid，openid是一種認證標准，規定如何認證的標准！即其關注的是登錄時身份的認證。官方給出的一個場景，其中一方是一個openid身份伺服器，用來存放注冊好的openid賬號，另一方是受這個openid身份伺服器信賴的服務或應用。openid協議就是提供openid身份伺服器和被信賴的服務或應用之間的通信的。比如我們在很多網站上可以使用QQ登錄，這里的騰訊的QQ就是openid的身份伺服器，我們所要登錄的網站就是受信賴的服務或應用。
在使用openid實現單點登錄的方法有很多，可以使用上面共享session的方法，即把openid帶在cookie裡面，但是這樣也會出現一樣的cookie跨域的問題。
在實際場景中，我們在訪問提供服務的應用時檢測到未登錄就會直接跳轉到openid身份伺服器，或者沒有重定向而是在登錄表單附近點擊選擇使用第三方openid登錄，進行賬號密碼登錄（這可以保證我們所登錄的伺服器無法獲取我們的敏感身份認證信息），具體流程如下：
CAS全稱為Central Authentication Service即中央認證服務，是一個企業多語言單點登錄的解決方案，並努力去成為一個身份驗證和授權需求的綜合平台。CAS就是一個現成的單點登錄的demo，企業只需要簡單修改就可使用。
CAS支持各種協議，SAML，OAuth，OpenID，OIDC等等，支持LDAP，Radius，JWTX，509等等進行身份認證和授權，還有各種常用語言的客戶端，Java，PHP，C# 等等。反正就是一個十分完整的，兼容性特別好的SSO框架。
簡單了解CAS是如何實現單點登錄的。在官網上可以看到其給出的一個 流程圖 ，。這個圖說的特別詳細，一下就能看懂，直接原圖上進行標注查看：
學習了上面幾種單點登錄的知識，結合實際場景可知，跨域單點登錄才是真正的單點登錄，因為實際情況下很多平台或者域名不可能都在一個一級域名下。在解決跨域單點登錄的問題的時候，上面也給說了幾種方式，但是究其根本，就是利用一個SSO認證中心來實現認證與授權的。當然，也會有其他的解決跨域單點登錄的方案，但是大體流程都與cas類似。
比如在上圖的11步驟，也可使用POST包，或者JSONP和iframe方法來跨域發送請求進行重定向。
在利用認證中心來實現單點登錄是現在比較普遍的解決方案，那麼有沒有不需要使用認證中心來解決跨域單點登錄的方案呢？
利用JSONP同步登錄狀態，大概流程流程如下：
在學習單點登錄的過程中，在其中認證的過程中授權令牌的傳遞等相關信息沒有特別詳細的說明，而且在思考單點登錄的時候也會有想過一個比較矛盾的問題：單點登錄的目標是為了讓用戶可以在相互信任的系統中一次登錄即可，但是如果真的是做到所有用戶都可以訪問所有系統，豈不是會帶來越權的問題，是否需要對不同的用戶以不同的授權，甚至限制訪問的應用，但是這樣是不是就不是原本狹義的單點認證？
在說單點登錄的認證和授權之前，先談一談我一直想弄清楚的統一身份認證和單點登錄的區別。說起單點登錄可能很少聽過，但是統一身份認證肯定不陌生，不管是企業還是高校都會有這種統一身份認證的系統。
統一身份認證最重要的一方面就是身份認證，另一方面就是和身份認證相關的授權控制，許可權控制。而單點登錄是多應用一次登錄，也可以叫統一登錄，可以理解為主要在認證方面。對於統一身份認證來說會有賬號管理，如LDAP，認證管理OAuth，SMAL等，因此我覺得，統一身份認證一般是包括狹義的單點登錄，狹義的單點登錄，即只需要滿足多應用一次登錄即可。但是現在的單點登錄，SSO系統並不僅僅是要求這些，他的范圍正在慢慢擴大。
單點登錄的認證和授權，前面說到的CAS實現單點登錄里就會看到需要ticket來進行認證，授權。CAS支持多種認證方案，比如OAuth，OpenID，SAML等等，我們可以來比較比較用這些協議的區別，或者說是在哪些場景下使用哪些認證方案較為合適。本身單點登錄是沒有許可權控制的功能的，但是因為這些認證協議的需求，自然支持了許可權控制。
在使用SAML進行認證的過程中，可以看到下圖，其是基本流程都差不多，這里需要注意的就是在用戶在認證中心成功登陸之後，重定向的時候返回的是一個SAML token，一個XML節點，這里的token會包括用戶的身份信息，用戶名等。
在OAuth2.0的標准中流程是和上面的基本相同，但是OAuth2因為客戶端並沒有一點是瀏覽器，所以token中默認是沒有簽名的。這里可能沒有體現出來，OAuth2的目標是授權，所以token更關注的是許可權，token在向認證伺服器驗證的時候就會有不同的授權，但是既然是授權，就間接實現了認證。
在傳統的認證中都是基於session機制的，具體的session模式上面也說了，根據其特性可知session的一些確定：
https://www.mutuallyhuman.com/blog/choosing-an-sso-strategy-saml-vs-oauth2/
https://yq.aliyun.com/articles/636281
https://juejin.im/post/5d0dbb7e6fb9a07f0420512d
⑹ 使用thinkphp框架實現單點登錄，服務端也要用tp，誰弄過
可以參考各大開源軟體的實現模式，如discuz的uc,phpcms的phpsso等