講講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呢？用統一的賬号登入，既能登入這些有年頭的軟體系統，能輕松接入現有流行的軟體系統，還能給未來待開發的軟體系統予以一定規範和幫助？