登陸的輪子，你還在造？

​講講LDAP，SAML，OpenID，OAuth2這些常見登陸協議以及它們背後的故事

登錄是個啥？

登陸這個操做，在咱們平常使用各種網站，應用的時候，幾乎是必需要作的事情。在計算機如此普及的今天，輸入帳號密碼，點擊登陸按鈕，咱們天天都要重複幹不少遍這樣的事情。那麼就是這個簡單的登陸按鈕，咱們去探究其背後的祕密。
看下一個最簡單的登陸過程，如圖：
是否是以爲很複雜，看着有點暈？

登陸按鈕背後，其實包含了註冊，登陸與認證，受權，鑑權與訪問，四個過程，一共四方參與其中來完成。

註冊，是登陸的前提。
用戶須要向網站代表本身是誰，就是網站會分配給用戶一個惟一的標識，一般就是用戶名，用來肯定用戶在瀏覽網站時的身份。對網站來講，主要的目的就是爲了將每一個用戶區分開來，進一步能夠將每一個用戶的行爲與數據區分開來，再進一步能夠創建用戶與用戶的關係。
註冊的結果，就是在數據庫中會保存下用戶的帳號密碼。爲了安全起見，通常密碼都會用MD5加密算法加密後保存，固然也不全是這樣。國內以前最大程序員社區網站CSDN由於被******，致使帳號密碼泄露，發現密碼是明文的，引起了很多吐槽，錯了，是不少吐槽。

登陸，目的是完成認證。
帳號密碼輸入完畢，點擊登陸按鈕，系統會將數據庫中的帳號密碼跟輸入內容進行比對，徹底相同，則認爲經過認證。認證，就是肯定這個用戶確實是他本身聲稱的那個用戶。

受權，纔是關鍵。
認證完成後，該用戶憑什麼能進入網站查看，這就須要受權。
重點來了！所謂受權，就是生成一個惟一的口令牌，常見的生成過程，就是將用戶名，登陸時間毫秒數，再根據我的喜愛，加一些其它口味的參數，通過MD5加密以後，生成的一串16進制的字符串。這個字符串就是口令牌。
爲了讓用戶不用每次來輸入帳號密碼，通常這個受權都會有一段有效時間。用戶只要憑藉有效的受權就能夠進入。

訪問，以前須要鑑權。
用戶得到受權後，對網站的其它功能頁面發起訪問。每次訪問，都要將口令牌做爲請求參數。口令牌失效，都會拒絕訪問請求。口令牌，通常兩種狀況下會失效。一是過時了，二是用戶主動退出登陸。通常口令牌都有時效性，也就是在固定的時間過去後，再憑藉這個口令牌訪問系統，系統就會拒絕訪問。過時時間越短，口令牌泄漏的可能性越小，安全性就越高。

整個過程就比如，用戶去某大廈參觀，先要在大廳前臺那，用身份證登記（註冊）；你往裏走就到總入口那，門口的保安隊長要求你出示身份證覈驗後（登陸與認證），會發給你參觀證（受權），上面寫着你是誰。保安隊長會告訴你，參觀證24小時有效，過了24小時，你須要從新來保安隊長這裏領取。用戶拿着牌子訪問大廈的每一個房間，在每一個房間門口都有一個保安，要求必須出示一下這個參觀證才放用戶進去（鑑權與訪問）。

這裏順便插一句，現實生活中，身份證就比如用戶名，用戶肉身就比如密碼。

上面就是最基本的登陸過程，在普通網站中基本夠用了。但在企業級產品裏，還不夠。由於一個企業裏面可不止一我的，而是一羣人。人一多，就天然有了組織結構。
下圖是個常見的企業組織結構：

企業的組織結構，像一顆倒過來的樹，在計算機術語裏，這種數據結構就叫樹（Tree）。那麼在數據庫中就須要經過數據來記錄這種組織結構關係，咱們定義一種叫組（Group）的概念，每一個組有個惟一標識：組名。當一個用戶屬於某個組時，在這個用戶的數據裏面記錄下這個組名便可。一樣，一個組的數據也能夠記錄另一個組名，表示這個組屬於另一個組。這裏看下來有點繞，總之重點就是用數據能表達出這種結構關係就是了。
有了這個結構後，受權的過程就會變得更加複雜了。
企業中的每一個人的權限是不一樣的。人數衆多狀況下，要給每一個人設置對應權限無疑是繁瑣的。正好，咱們能夠利用組織結構，不一樣的組擁有不一樣的權限，經過人在不一樣組裏面，表現出不一樣的權限。
所以，受權的過程，就須要查看用戶所在的全部組所對應的權限，來判斷用戶是否有訪問當前功能頁面的權利。

說到這裏，才真正把登陸有關的關鍵點都說了一遍，沒看明白就再多看幾回。讀書百遍，其義自見。而後你覺得要結束了嗎？沒有，登陸的故事其實才剛剛開始...

登陸的發展

隨着集成電路，半導體等技術的發展，計算機硬件設備愈來愈普及，與此同時互聯網也快速發展。在1980-1990年代，是飛速發展的時期。大量的企業開始使用計算機做爲主流的辦公工具。這時候，企業對軟件的需求變得愈來愈大。
企業內部軟件系統愈來愈多，簡單的登陸就帶來了不少困擾：

• 各個系統都要求員工註冊登陸；
• 每一個系統中都須要維護各自的組織結構；
• 等一個員工要離職的時候，還須要在每一個系統中將此員工帳號清除；
• 若是同一員工在不一樣系統的帳號密碼還不一樣，忘記帳號密碼就是再廣泛不過的狀況了；

因而計算機的先賢們，就想能不能將維護用戶的帳號密碼，公司的組織結構不要如此繁瑣？每一個用戶只須要一個帳號密碼，整個公司也只須要一個組織結構呢？
回顧下登陸的流程，咱們將帳號密碼，組織結構獨立出來，作成單獨的軟件系統。那麼帳號密碼，組織結構這些數據的保存，就都在這個獨立的登陸服務系統中，那麼驗證帳號密碼也能夠在登陸服務中就完成了。如圖：

在1988年，由當時的國際電報電話諮詢委員會（CCITT）推出的X.500計算機目錄服務的標準系列協議中，包含由大名鼎鼎的互聯網工程任務組（IETF）設計的LDAP協議（Lightweight Directory Access Protocol，輕型目錄訪問協議）。IETF就是設計TCP/IP協議族的那個標準組織。
協議，其實就是一個文檔說明。就是一羣大神發現，爲了解決相同的問題，菜鳥們造出各類千奇百怪的輪子出來，看着實在難受。因而大神們聚在一塊兒開了個會，甩出一篇文檔說：照這個作就行。
LDAP協議是基於IP協議上的，意思就是基於互聯網，得有網絡才能工做。
LDAP協議主要規範了數據存儲方式，以及驗證帳號密碼的過程。LDAP要求帳號密碼，組織結構這些信息都保存在其系統中。LDAP也只負責對帳號密碼進行驗證，其它好比該帳號是否有權限訪問當前應用，口令牌相關的驗證，應用內部的權限等都不在LDAP的關心範圍之類。
LDAP協議中，除了驗證帳號密碼這個額外的功能外，看上去更像一個數據庫，只負責數據存儲和讀取。它是特別的爲了這種數據和數據之間互相關聯的數據結構而設計的，這種東西，有個特殊的名字叫：目錄服務（Directory service）。LDAP是目錄服務中的一種。
目錄服務的特色，就是讀取快，寫入慢。適合頻繁讀取而不常常寫入的數據存儲。目錄服務的應用範圍實際很是之廣，有興趣能夠去了解一下。
LDAP有各類各樣的實現，實現的意思就是一些公司或者我的，按照LDAP的協議，用代碼真正的寫出來了一個可運行的軟件系統。
著名的LDAP實現有：

• 微軟的AD（Microsoft Active Directory）
• 開源維護的OpenLDAP

對於通常軟件應用，咱們若是稱某個應用兼容LDAP協議，也就是意味着，這個應用實現了對LDAP讀寫的API，這樣只須要提供LDAP服務的IP地址等必要信息，該應用就能使用LDAP做爲其帳號密碼驗證的服務了。固然，具體不一樣應用對LDAP的使用方法多有不一樣，會存在不大不小的差別。
在LDAP的基礎上，很好的解決了系統管理員要維護好多份公司結構和帳號密碼的問題，對於員工來講，也只須要記住一個帳號密碼就能夠登陸全部系統了。這在企業內部系統使用來看，彷佛夠用了。

也就在LDAP協議誕生後一年，1989年英國科學家 蒂姆·伯納斯-李 發明了萬維網。蒂姆·伯納斯-李，就是圖片上這位神仙。

Web領域常常說起的三個概念：

• 全球網絡資源惟一認證系統，統一資源標誌符（URI）；
• 超文本標記語言（HTML）；
• 超文本傳輸協議（HTTP）
  都是他的我的發明，他還在1990年寫編寫了第一個網頁瀏覽器。（拜拜Web之神，保佑網頁不崩）

Web時代到來啦！
以前的互聯網，網站方須要將本身的內容分享出來都要求用戶安裝特定的應用程序（沒錯，就跟如今手機APP差很少）。網站方要提供特定程序，對開發難度無疑是個挑戰。並且在上世紀90年代初 ，撥號上網的滋滋聲伴隨的是幾KB的網速，用戶要下載安裝各類五花八門的應用在本身那容量可憐的電腦裏，對用戶簡直是個災難。
Web的出現就完全改變這一切。名叫WorldWideWeb的萬維網在以後幾乎成爲互聯網的代名詞。網頁瀏覽器成爲用戶鏈接世界的窗口。也正由於Web的發展，普通人買臺電腦放在家裏再也不像是個擺設。
隨着網站愈來愈多，網站類型愈來愈豐富，從開始只是徹底開放式的只讀網頁，到逐漸擁有一些功能，須要區分用戶行爲，設定用戶權限等等。
是的，他來了，他來了，咱們的主角登陸又出場了，網站也須要登陸了。

Web系統開發起來簡單，使得網站爆炸式增加，即便同一家公司也擁有多個網站服務。而用戶這邊，爲了記住這麼多網站的帳號密碼而疲憊不堪。相對於Web的易用性，登陸各個網站都須要不停的輸入帳號密碼顯得格外繁瑣。
能不要這麼麻煩嗎？
1998年，微軟推出了Passport network服務，提供一個全球統一的用戶身份服務。網絡護照，顧名思義，就是用戶註冊Passport以後，將用戶資料，如：名字，年齡，照片等等信息上傳給Passport。其它網站接入Passport以後，用戶在使用時就無需再次登陸，用戶只須要完成Passport的登陸便可。這種一次登陸就能夠訪問其它網站的理想，被稱爲單點登陸（single sign-on，SSO）。
Passport失敗了，大概是由於人們不信任微軟。可是SSO的理念卻引發了同行們的注意。SSO的想法就是將身份提供者（Identity provider，IDP），服務提供者（Service provider，SP）完全分離，用戶用IDP提供的身份就能夠在Web世界暢通無阻。
這裏面最讓人頭疼的實際上是安全問題。如何保證用戶的身份在邏輯上不能被冒充，纔是最難的題目。數據加密，數字簽名（Digital Signature）等各類密碼學知識恰好解決了這個問題。這就是另一大塊的內容，暫且按下不表。

在2001年由OASIS組織安全服務技術委員會(Security Services Technical Committee)推出了SAML（安全主張標記語言，Security Assertion Markup Language），就是提出了對SSO實現的總體技術和安全規範。
SAML是以XML爲基礎，不用JSON的緣由，大概是由於JSON一直在1999年才發明，2004年之後才流行起來逐漸取代了XML。在這以前，XML一直是做爲網絡通信的標準格式。
在SAML協議中，實際上也包含了能夠發送帳號屬性等登錄外的擴展部分。SAML協議實際內容不少，就不一一介紹，這裏只圍繞單點登陸來講明。
SAML協議裏，約定了參與SSO的三方：瀏覽器，身份提供者（IDP），服務提供者（SP），以及這三方相互的通信次序，加密方法，傳輸數據格式。
在2005年推出了SAML 2.0，與老版本1.1互不兼容，可是解決的問題思路是同樣的，2.0也是最新的協議，大概流程以下圖：

跟LDAP的流程作一個對比，LDAP協議裏只負責用戶身份的認證，不包含受權過程。在SAML協議中，不只包含身份認證，還包含是否容許用戶訪問當前網站內容的受權部分。
LDAP服務與應用之間是毫無條件的充分信任，LDAP幾乎是做爲應用的遠程數據庫通常的存在。而在SAML中，SP與IDP不只須要在事前互相信任（互換籤名公鑰與IP地址），還要在認證過程當中防止他人僞造而進行數據校驗。由於SAML定義的SP與IDP是在互聯網上相互獨立的站點。
同時能注意到SAML協議很是依賴瀏覽器重定向功能，而LDAP協議都是應用與LDAP服務間的直接通信。
瀏覽器重定向，其實就是指當前你訪問的頁面主動跳轉到另一個網站的網頁上去，在跳轉的過程當中能夠給此次訪問網頁的請求上附加上一些數據用來完成數據傳輸。

SAML的介紹差很少這些，這裏我就不打算給你作一個什麼生動形象的比喻來幫你理解這個事情了，相對有點抽象，反覆看幾遍，畢竟後面的更抽象。

實際上，除了SAML之外，同期還有很多其它協議或者方法提供SSO的解決方案，本質上都大同小異。任何SSO方案裏，SP與IDP這兩個概念都是最關鍵的兩個角色。
在Web世界裏，SSO理念被你們承認，也就獲得了普遍的應用。好比如今咱們在不少網站提供的微信登陸，微博登陸，都是SSO的一種實現。
互聯網公司的某個產品用戶有一點基數，就但願經過登陸進一步擴大本身的影響，都紛紛實現本身的SSO方案。因而網上就會充斥着很是多的登陸。國外就有Google登陸，Facebook登陸，Twitter登陸等等，國內就有微信登陸，微博登陸，QQ登陸，支付寶登陸等等，也不少。你一個互聯網公司沒個登陸都很差意思跟人打招呼。

像圖片上這樣，看着是否是也挺鬧心的。
對用戶來講，這些互聯網產品我都得用啊，不是說好的用了SSO我就只須要一個帳號密碼了嗎？咋仍是這樣呢？
再看看各大互聯網公司，業務之間多少存在互相競爭，誰也不待見誰，統一？打通？門都沒有。感受SSO最初的美好願望就要落空了。
寫到這裏，按照基本劇情，英雄就該出現了。

一個叫布萊德的程序員在1999年的時候，開發了一個相似博客同樣的社區網站。運營的還不錯，有了好幾百萬用戶。你看，互聯網公司，幾百萬用戶，感受能夠開始作本身的SSO登陸了。可此次布萊德不想作一個跟巨頭們同樣的東西，畢竟就算作出來估計也打不過。那要不要嘗試去中心化的路子？
去中心化這個概念隨着比特幣流行而火爆了起來，其實去中心化這個概念很早就有了。中心化的意思就是用戶在使用某項服務時，全部的訪問請求都須要向同一個主體的服務器地址發送。好比每一個微信用戶的客戶端，都是在跟騰訊公司的服務端交流，A發送給B一條消息，都是A先發送給騰訊服務端，再由騰訊服務端轉發給B。A是不能經過其它公司或我的的服務端發送給B消息的。相似這樣，全部用戶都圍着中間一個服務端，就管這種叫中心化的服務。
去中心化呢？就是並無固定的一個服務商提供服務，任何人只要他願意的話，均可以做爲服務端來給用戶服務，用戶也能夠自由的切換服務端。這種方式顯然是不符合已經擁有大量用戶的互聯網公司的利益，但卻迎合了用戶和中小企業抱團取暖的需求。
因而布萊德在2005開始了一個叫OpenID的項目開發，這個項目在軟件社區中獲得了響應，愈來愈多的人蔘與進來，以後愈來愈多的人開始使用。OpenID的目的就是創建一個統一的SSO的方式，而不用在乎IDP服務的提供方。用戶徹底能夠本身啓動一個IDP的服務，或者選擇一個用戶信任的IDP服務提供方，在這個IDP服務上完成註冊。那麼只要SP站點能使用OpenID的方式，用戶就能夠完成登陸了。
大體流程如圖：

由於提供OpenID的IDP服務並不肯定在哪，因此在打開IDP的登錄頁面以前，用戶須要在SP提供的一個符合OpenID標準的表單上，輸入下本身帳號所在的IDP地址信息，以便讓SP找到相應的IDP服務。
並且值得注意的是，OpenID只提供了認證，而並無受權。也就是說OpenID的IDP只確認了確實有這個帳號，而這個帳號能不能訪問該網站的內容，OpenID的IDP並不關心。
OpenID這種去中心化的特色，讓帳號這種資源或者權力再也不被大企業獨佔而成爲一種可能，在社區裏面很快就廣受歡迎。此後國外的一些主流網站也逐漸開始支持OpenID，國內互聯網公司估計還沒那麼快想得開。

在2006年，在Twitter工做的庫克正在負責給Twitter支持OpenID的工做。與此同時，社交書籤網站Ma.gnolia須要一個解決方案容許使用OpenID的成員受權Dashboard訪問他們的服務。
來，咱們來理解一下這個需求。
用戶用同一個帳號在甲乙兩個站點都有登陸，甲想要調取乙的數據，一般要訪問乙，都須要乙的口令牌，才能訪問，那若是將乙的口令牌直接告訴甲，那就至關於甲在乙那邊有跟用戶相等的權力，很難保證甲不拿這些去幹些越權的事情。那麼，在不將乙的憑證交給甲的前提下，咱們是否是能夠額外給甲一個臨時受權，這個臨時受權，規定好使用時效和使用範圍就能夠了。乙收到這個臨時受權，必定要覈驗一下究竟是哪一個用戶，這樣才能準確的給出資源。
基本流程如圖：

因而，庫克跟幾我的湊一塊兒鼓搗了近一年，在2007年推出OAuth協議草案，翻譯過來叫「開放受權」，算是給OpenID的一個補充。

你看時間已經來到了2007年，2007發生了一件大事情。
喬布斯發佈了第一代蘋果手機。

緊接着2008年HTC推出了第一部Android手機，完全拉開了移動互聯網時代的序幕。Web彷佛一時間跟失寵了同樣，開發者們大量的投入到了手機APP的開發中去。
以前的SAML協議十分依賴瀏覽器的重定向功能，在移動手機時代就顯得過期了，很差用了。OAuth1.0也是在Web時代誕生的，並且由於第一個版本太複雜，雖然有一些人發現其價值，但一直動靜不大。在2009年還發現協議裏有個安全漏洞，雖而後來打了個補丁，可是總歸影響不太好。
因而OAuth團隊就乾脆放棄了第一個版本。在2011年5月發佈了OAuth2.0草案。OAuth2關注客戶端開發者的簡易性，同時爲Web應用、桌面應用、手機和智能設備提供專門的認證流程。

如今大部分常見的登陸後面都借鑑了OAuth2的受權流程，好比在用微信登陸了一個網站後，老是還要彈出一個頁面，問你允不容許該網站使用你的微信頭像和名字，這就是受權的過程。只是在微信這個例子裏面，IDP和第三方服務都是微信一方。
另外從流程圖咱們能夠了解到，IDP與SP都是須要互相知道對方的位置，而且在受權流程開始以前，都須要互換公鑰來保證信息安全不被僞造，這就是OAuth2的註冊過程。
這上面的例子主要是Web下的流程，手機和桌面應用的流程會有所區別，這個感興趣能夠本身查閱相關資料。

在OAuth2推出以後，OpenID的團隊在2014年將OAuth2的理念與OpenID相結合，並做出一些簡化，發佈了OpenID Connect協議。簡單理解OpenID Connect就是認證跟OpenID同樣，受權跟OAuth2同樣。其實內部技術細節有很多差異，但這裏就不細說了。

就這樣，伴隨着軟件和互聯網的發展，登陸相關技術也隨着大神和英雄們的出現悉數登場。從LDAP，SAML，OpenID，OAuth2這一路的發展，也不太短短30年光景，不得不感慨計算機技術突飛猛進的速度。
企業信息化水平也隨着計算機技術的發展不斷進步，企業依賴軟件的程度也愈來愈高。企業使用的這些軟件，由於不一樣的時間，不一樣的需求，而採用了各類不一樣的登陸技術，這使得企業內部想作到真正意義上的SSO依然面臨諸多問題。
那咱們能不能再進一步去解決這些問題，至少在企業內部能真正意義上作到SSO呢？用統一的帳號登陸，既能登陸這些有年頭的軟件系統，能輕鬆接入現有流行的軟件系統，還能給將來待開發的軟件系統予以必定規範和幫助？

龍歸科技在2019年開發並推出一款代號ArkID開源項目：龍歸一帳通，就是針對企業目前在實現SSO方面的問題而提出的解決方案。

ArkID兼容本文介紹的和沒介紹的現有流行的各種用戶登陸協議，包括LDAP，SAML2，OpenID，OAuth2等等，同時ArkID還對外提供完整的API，方便接入各類新老系統，完成真正的單點登陸。
ArkID支持帳號同步，各種第三方帳號登陸（如微信，釘釘等），支持企業組織結構，支持應用受權。
ArkID徹底能夠跟LDAP同樣，做爲遠程帳號與組織結構數據庫，甚至支持了對應用內權限的相關數據存儲。
ArkID提供的登陸頁面，容許自定義名字和顏色。同時將基於Vue的前端頁面和管理後臺開源，能夠爲所欲爲的定製。
ArkID一樣支持了完整的登陸日誌，支持了用戶行爲審計。

一帳通產品頁：https://www.longguikeji.com/product/arkid
源代碼：https://github.com/longguikeji/arkid-core