單點登入如何解決身份認證問題？
那麼單點登入（Single Sign On，SSO）到底是什麼呢？單點登入的概念很簡單：使用者隻需要進行一次認證，就可以通路所有的網頁、應用和其他産品了。随着網際網路産品形式的不斷發展，單點登入的實作方式也經曆了多次的更新革新。下面我為你介紹幾種典型的單點登入方式，它們分别是：CAS 流程、JWT、OAuth 和 OpenID。
第一個要講的是 CAS（Central Authentication Service，集中式認證服務）流程。
CAS 是一個開源的單點登入架構，它不屬于某一種單點登入的實作方式，而是提供了一整套完整的落地方案。整體的流程如下圖所示，具體步驟我會通過通路極客時間 App 的例子來為你詳細講解。
- 假如使用者現在要通路某個應用，比如知乎APP。
- 應用需要進行認證，但應用本身不具備認證功能。是以，應用将使用者重定向至認證中心的頁面。比如，你在登入一個應用的時候，它顯示你可以選擇微信、QQ、微網誌賬号進行登入，你點選微信登入，就跳轉至微信的登入頁面了。
- 使用者在認證中心頁面進行認證操作。如果使用者之前已經在其他應用進行過認證了，那麼認證中心可以直接識别使用者身份，免去使用者再次認證的過程。
- 認證完成後，認證中心将認證的憑據，有時會加上使用者的一些資訊，一起傳回給用戶端。也就是你在微信登入完成後，回到了極客時間 App。
- 用戶端将憑據和其他資訊發送給應用，也就是說，極客時間 App 将微信的登入憑據發送給了極客時間後端。
- 應用收到憑據後，可以通過簽名的方式，驗證憑據的有效性。或者，應用也可以直接和認證中心通信，驗證憑據并擷取使用者資訊。這也就是為什麼極客時間能夠拿到你的微信頭像了。使用者完成認證。
CAS 的流程非常經典，你現在應該了解了吧？我們後面要講的 3 種單點登入方式，都和 CAS 的流程相似，說它們是 CAS 的“衍生品”也不為過。是以說，你一定要先掌握了 CAS 流程，然後再來看下面這 3 種。
JWT（JSON Web Token）是一種非常輕量級的單點登入流程。它會在用戶端儲存一個憑證資訊，之後在你每一次登入的請求中都帶上這個憑證，将其作為登入狀态的依據。JWT 的好處在于，不需要應用服務端去額外維護 Cookie 或者 Session 了。但是，正是因為它将登入狀态落到了用戶端，是以我們無法進行登出等操作了。
OAuth（Open Authorization）的主要特點是授權，也是我們通常用 QQ、微信登入其他應用時所采用的協定。通過 OAuth，使用者在完成了認證中心的登入之後，應用隻能夠驗證使用者确實在第三方登入了。但是，想要維持應用内的登入狀态，應用還是得頒發自己的登入憑證。這也就是為什麼 QQ 授權後，應用還需要綁定你的手機号碼。這也就意味着，應用是基于 QQ 的資訊建立了一個自身的賬号。
OpenID（Open Identity Document）和 OAuth 的功能基本一緻。但是，OpenID 不提供授權的功能。最常見的，當我們需要在應用中使用微信支付的時候，應用隻需要收集支付相關的資訊即可，并不需要擷取使用者的微信頭像。
在實際情況中，基于各種業務需求的考慮，很多公司都傾向于自己去實作一套 SSO 的認證體系，它的認證流程如下圖所示：
在這個流程中，應用的伺服器直接接收使用者的認證資訊，并轉發給認證中心。對使用者來說，這個認證中心是完全透明的。但是，這個流程給予了應用過多的信任，從安全性方面考量的話，是不合理的。在這個過程中，應用直接擷取到了使用者的認證資訊，但應用能否保護好這些資訊呢？我們并沒有有效的辦法去做确認。
是以，我的建議是，多花一些功夫去接入成熟的單點登入體系，而不是自己去實作一個簡化版的。JWT 适用範圍廣，在單點登入的選取上面，如果想要将使用者資訊做統一管理，選擇它最為簡單；如果認證中心隻是被用來維護賬号密碼，由業務去維護使用者所綁定的其他手機等資訊，那麼，采用 OAuth 更合适。
寫在最後：
有些公司是這樣的情況：應用服務和中間件（這兩個以下簡稱服務）部署在公司的機房裡，服務通過nginx對外暴露。nginx在機器A上，其餘服務在機器B~N，公司的安全人員要掃描所有機器上的應用。個人感覺如果機器B~N上做好防火牆設定，隻需要關系機器A上的安全問題就可以了，機器B~N不對外暴露，覺得在應用服務層面就沒有安全問題了。
實際上這麼做，一定程度上能緩解安全問題。比如nginx如果隻暴露80端口，那麼B~N的漏洞則主要集中在Web漏洞上。但是，内網并不是絕對安全的，通過Web漏洞，也可以實作内網穿透，通路内網的其他服務。如果你的防火牆隻是做在A和BN之間，那麼對于這種橫向滲透，就起不到防禦作用了。
我們現在已經越來越習慣用這種通過微信/微網誌或者其他CAS來認證登陸的場景了，那在CAS完成認證過程後，登陸憑據是如何從CAS伺服器轉移到欲登陸的APP中的呢。我們知道Cookie等内容都是嚴格遵循浏覽器的同源政策的，就算使用30X跳轉，設定的Cookie也隻能存在CAS域名内。實際上跳轉使用的的是類似在Reloacation的URL後面跟上認證憑證跳轉實作的。不過在網頁中，一般是會生成一個form表單，表單的内容就是各種憑證，然後送出的時候，相當于以POST請求跳轉到新頁面，這樣傳遞資訊的長度也不受限制。具體可以看一下，SAML，網頁時代比較流行的單點登入機制。