從2000年開始，在如何存儲(chǔ)和使用身份信息、保障用戶能夠訪問應(yīng)用程序、跨應(yīng)用的數(shù)據(jù)共享一直在不斷升級(jí)。每隔幾年時(shí)間，就會(huì)有新的需求和挑戰(zhàn)，當(dāng)然也會(huì)有對(duì)應(yīng)新的方案，每一次升級(jí)都解決了一些問題，但也帶來了新的問題。
了解過去，以示未來
不同時(shí)期的身份技術(shù)具有特定突出的優(yōu)點(diǎn)，當(dāng)然也有缺點(diǎn)，這些優(yōu)點(diǎn)和缺點(diǎn)可以幫助您更好的評(píng)估項(xiàng)目的身份解決方案。
身份發(fā)展概要
按照時(shí)間回顧下身份發(fā)展的歷史。
第一階段：石器時(shí)代，各個(gè)應(yīng)用使用獨(dú)立的身份體系、獨(dú)立進(jìn)行認(rèn)證和存儲(chǔ)身份，后來基于Cookie進(jìn)行內(nèi)部應(yīng)用的單點(diǎn)登錄。
第二階段，電氣時(shí)代——聯(lián)合身份，2003年為了解決企業(yè)應(yīng)用的聯(lián)合認(rèn)證的問題，微軟聯(lián)合、IBM等傳統(tǒng)IT巨頭發(fā)起了基于WS*系列標(biāo)準(zhǔn)之上構(gòu)建的WS-Federation1.1版本，但這一協(xié)議因?yàn)檫^于重，除了得到微軟的積極擁護(hù)以外，其他軟件廠商響應(yīng)屈指可數(shù)。因此在2005年，SAML2.0橫空出世，其協(xié)議的相對(duì)WS-Fed更為簡(jiǎn)潔明了，更適合SaaS應(yīng)用的發(fā)展，得到了SaaS廠商的支持。
第三階段，互聯(lián)網(wǎng)時(shí)代——面向消費(fèi)者共享身份，隨著互聯(lián)網(wǎng)、移動(dòng)互聯(lián)網(wǎng)的相繼爆發(fā)，OpenID和Oauth應(yīng)運(yùn)而生，并且得到廣泛的應(yīng)用。在2012年以前，互聯(lián)網(wǎng)的應(yīng)用之間的信息交互較少。隨著互聯(lián)網(wǎng)爆發(fā)式增長(zhǎng)，讓資源相互調(diào)用的需求迅猛增長(zhǎng)，Oauth2.0就此誕生，讓互聯(lián)網(wǎng)應(yīng)用之間的交互變得更加便捷。
第四階段，云時(shí)代——身份和授權(quán)標(biāo)準(zhǔn)化，因?yàn)榧夹g(shù)的演進(jìn)，對(duì)于API的授權(quán)需求越來越多，2014年基于OpenID和Oauth2.0，OIDC于2014年發(fā)布，谷歌、微軟、PingIDentity紛紛轉(zhuǎn)向這一新的協(xié)議。微服務(wù)、云原生這幾年概念火熱，可以預(yù)見OIDC的應(yīng)用將會(huì)越來越廣泛。
石器時(shí)代
獨(dú)立存儲(chǔ)身份
在石器時(shí)代的計(jì)算機(jī)應(yīng)用程序中，每個(gè)應(yīng)用程序通常實(shí)現(xiàn)自己的身份存儲(chǔ)庫、身份驗(yàn)證和授權(quán)。
這種煙囪式應(yīng)用構(gòu)建讓90%的應(yīng)用都存在相同安全風(fēng)險(xiǎn)。用戶的登錄體驗(yàn)是割裂的，用戶的身份信息無法獲得同步。在企業(yè)場(chǎng)景下，當(dāng)只有幾個(gè)應(yīng)用程序時(shí)，用戶對(duì)數(shù)據(jù)完整性問題的惱怒和必須記住的幾個(gè)密碼體驗(yàn)就足夠糟糕了。然而，隨著企業(yè)中應(yīng)用程序數(shù)量的增長(zhǎng)，讓每個(gè)應(yīng)用程序?qū)崿F(xiàn)自己的筒倉式身份存儲(chǔ)庫和身份驗(yàn)證解決方案很快就變得難以支撐。
這種孤立的方法目前仍在許多面向消費(fèi)者的場(chǎng)景中使用，其中用戶通過提供特定于應(yīng)用程序的用戶名和密碼進(jìn)行注冊(cè)。如果一個(gè)用戶在多個(gè)站點(diǎn)上重復(fù)使用同一個(gè)密碼，任何一個(gè)站點(diǎn)上的泄露都可能使該用戶的數(shù)據(jù)在其他站點(diǎn)上受到威脅。如果用戶為每個(gè)應(yīng)用程序指定不同的密碼，他們必須記住或安全地存儲(chǔ)密碼，或者依賴應(yīng)用程序提供的帳戶恢復(fù)過程的安全性。
目錄服務(wù)
很快，人們發(fā)現(xiàn)，如果采用集中式的目錄來存儲(chǔ)用戶的身份信息將帶來無可比擬的優(yōu)勢(shì)。
支持目錄復(fù)制功能的托管應(yīng)用程序 在世界各地利用相同的身份信息，消除數(shù)據(jù)不一致的問題。應(yīng)用程序之間可以使用相同的用戶名和密碼。集中式目錄服務(wù)還提供了一個(gè)控制點(diǎn)，在這個(gè)控制點(diǎn)上可以實(shí)現(xiàn)密碼策略或在必要時(shí)快速終止標(biāo)識(shí)。因此，目錄服務(wù)被廣泛采用，至少在大公司是如此。
目錄服務(wù)對(duì)于身份管理帶來了極大的提升，但是目錄服務(wù)沒有維護(hù)任何的應(yīng)用會(huì)話。因此，仍然沒有解決用戶反復(fù)輸入身份信息、授權(quán)等等問題。同時(shí)，也將用戶的憑據(jù)暴露給了應(yīng)用。一個(gè)應(yīng)用程序中的淪陷可能會(huì)使其他應(yīng)用程序處于危險(xiǎn)之中。當(dāng)所有涉及的應(yīng)用程序都在可信的公司網(wǎng)絡(luò)中時(shí)，這種情況就尚且可以容忍。隨著公司開始使用云應(yīng)用程序，向云應(yīng)用程序公開目錄密碼被其他人擁有會(huì)帶來不可接受的風(fēng)險(xiǎn)。再一次，需要一個(gè)更好的解決方案！
電器時(shí)代-聯(lián)合身份
在身份目錄的基礎(chǔ)上，構(gòu)建一層身份會(huì)話層，用于維護(hù)身份登錄的的信息，理所當(dāng)然的成為目錄服務(wù)的改進(jìn)方案，即單點(diǎn)登錄-SSO。
與目錄服務(wù)相比，單點(diǎn)登錄服務(wù)SSO的引入提供了許多優(yōu)勢(shì)。用戶可以通過一次身份驗(yàn)證訪問多個(gè)應(yīng)用程序，因此受益匪淺。用戶的靜態(tài)目錄密碼只向SSO服務(wù)器公開，而不是向用戶訪問的每個(gè)應(yīng)用程序公開。IT部門很高興，因?yàn)樗鼮樗麄冊(cè)趩我晃恢锰峁┝藢?shí)現(xiàn)身份驗(yàn)證策略和更強(qiáng)大的身份驗(yàn)證機(jī)制。
早期的單點(diǎn)登錄服務(wù)依賴于cookie，由于瀏覽器對(duì)cookie訪問的限制，這意味著解決方案可以在一個(gè)Internet域內(nèi)工作，而不能跨域。由于許多公司開始采用外部軟件即（SaaS）服務(wù)，這一限制就尤為明顯。
接下來可想而知，對(duì)于SSO的改進(jìn)，就成為很多大公司（如微軟、IBM等）創(chuàng)新的方向。
身份開始逐漸走向標(biāo)準(zhǔn)化，這里不得不提到的是OASIS（Organization for the Advancement of Structured Information Standards）結(jié)構(gòu)信息標(biāo)準(zhǔn)化促進(jìn)組織。其中，WS-Fed和SAML均捐贈(zèng)了給OASIS。
聯(lián)合身份-WS-Fed
2002年4月11日，微軟、IBM和VeriSign三公司聯(lián)合發(fā)表了Web服務(wù)的新安全規(guī)格“WS-Security”和Web安全藍(lán)圖“Security in a Web Services World”。在當(dāng)時(shí)的安全藍(lán)圖說明中就包括了WS-Federation規(guī)范的基本輪廓。并于2003年7月9日發(fā)布規(guī)范的說明草案。
2009年，WS-Fed1.2規(guī)范正式作為OASIS的標(biāo)準(zhǔn)發(fā)布。該版本提供了“可以向在其他領(lǐng)域管理其身份的安全主體提供對(duì)在一個(gè)領(lǐng)域中管理的資源的授權(quán)訪問”的機(jī)制，該標(biāo)準(zhǔn)得到了微軟ADFS服務(wù)器以及許多其他商業(yè)SSO產(chǎn)品和服務(wù)的支持。
WS-Federation（簡(jiǎn)稱: WS-Fed )聯(lián)合框架屬于Web Services Security(簡(jiǎn)稱: WS-Security、WSS: 針對(duì)web-service安全性方面擴(kuò)展的協(xié)議標(biāo)準(zhǔn)集合) 的一部分。WS-Federation規(guī)范采用了XML以及其他Web服務(wù)標(biāo)準(zhǔn)，從而可以使開發(fā)者能夠?qū)崿F(xiàn)在不同環(huán)境下的網(wǎng)絡(luò)安全管理及建立相互協(xié)調(diào)信賴關(guān)系的目的。
不用看協(xié)議的具體內(nèi)容，光看到協(xié)議的框架，就可以感知到整個(gè)協(xié)議的功能之強(qiáng)大，細(xì)節(jié)之周全。然而，這也意味著實(shí)現(xiàn)起來會(huì)比較重，因此，除非為了能和微軟的服務(wù)整合，才會(huì)優(yōu)先考慮該協(xié)議。所以，該協(xié)議主要用于微軟自己的生態(tài)。
而對(duì)于互聯(lián)網(wǎng)或是SaaS服務(wù)廠商，更愿意選擇SAML。
聯(lián)合身份 SAML2.0
SAML 2.0在2005年三月正式代替SAML 1.1成為OASIS標(biāo)準(zhǔn)。來自超過24個(gè)公司及團(tuán)體的大約30人參與了SAML 2.0的創(chuàng)建。尤其是，自由聯(lián)盟將身份聯(lián)合框架規(guī)范（ID-FF）貢獻(xiàn)給OASIS，后者成為了SAML 2.0規(guī)范的基礎(chǔ)。
它提供了跨域和聯(lián)合身份的web單點(diǎn)登錄解決方案。這恰好適合于使用SaaS應(yīng)用程序的企業(yè), SAML 2.0為需要在SaaS應(yīng)用程序中更好地控制員工身份的企業(yè)提供了一個(gè)極好的解決方案。
SaaS應(yīng)用程序可以將企業(yè)用戶重定向回企業(yè)身份驗(yàn)證服務(wù)（稱為身份提供者（IdP））進(jìn)行身份驗(yàn)證。身份聯(lián)合基于網(wǎng)絡(luò)跨域的單點(diǎn)登錄(SSO)， 以便于減少向一個(gè)用戶分發(fā)多個(gè)身份驗(yàn)證令牌的管理開銷。用戶也只需記住一個(gè)用戶名/密碼，而無需反復(fù)登錄。無論是對(duì)內(nèi)部和外部應(yīng)用，SAML賦予企業(yè)一個(gè)集中控制點(diǎn)，如果需要，可以在企業(yè)身份提供者處快速關(guān)閉一個(gè)用戶的訪問權(quán)限。密碼策略和多因素身份驗(yàn)證也可以在一個(gè)地方實(shí)現(xiàn)，通過這種方式，SAML2.0解決了企業(yè)的許多身份問題。
SAML2.0的不足之處
盡管被廣泛采用，但是SAML2.0并不是萬能的。該協(xié)議被設(shè)計(jì)為覆蓋許多場(chǎng)景，使得配置和實(shí)現(xiàn)仍然復(fù)雜。雖然SAML2.0在企業(yè)環(huán)境中被廣泛采用，但是沒有一個(gè)可行的業(yè)務(wù)模型來解決面向消費(fèi)者的場(chǎng)景。另一個(gè)限制是SAML2.0只解決了身份驗(yàn)證問題，而沒有解決API的授權(quán)問題。應(yīng)用程序正在向基于微服務(wù)、API的體系結(jié)構(gòu)發(fā)展，正如通常實(shí)現(xiàn)的那樣，SAML2.0解決了對(duì)用戶進(jìn)行身份驗(yàn)證的問題，但對(duì)API授權(quán)沒有幫助。
互聯(lián)網(wǎng)時(shí)代的身份
SAML2.0只在面向員工的場(chǎng)景中采用，消費(fèi)者用戶仍然被迫在每個(gè)面向消費(fèi)者的網(wǎng)站上重新注冊(cè)。因此，“以用戶為中心”的身份解決方案正在萌芽，并由此產(chǎn)生了一個(gè)稱為OpenID的協(xié)議。
OpenID
OpenID是一個(gè)去中心化的網(wǎng)上身份認(rèn)證系統(tǒng)。對(duì)于支持OpenID的網(wǎng)站，用戶不需要記住像用戶名和密碼這樣的傳統(tǒng)驗(yàn)證標(biāo)記。取而代之的是，他們只需要預(yù)先在一個(gè)作為OpenID身份提供者（identity provider, IdP）的網(wǎng)站上注冊(cè)。OpenID是去中心化的，任何網(wǎng)站都可以使用OpenID來作為用戶登錄的一種方式，任何網(wǎng)站也都可以作為OpenID身份提供者。OpenID既解決了注冊(cè)問題而又不需要依賴于中心性的網(wǎng)站來確認(rèn)數(shù)字身份。
與面向組織控制的身份提供者 （Saml2.0和WS-Fed）不同，OpenID則提供了面向用戶控制的消費(fèi)者身份的協(xié)議。那么互聯(lián)網(wǎng)時(shí)代的消費(fèi)者身份問題被解決了，但是有新的問題需要解決，即消費(fèi)者的數(shù)據(jù)權(quán)限，并為此產(chǎn)生了Oauth 授權(quán)協(xié)議。
Oauth2.0
Oauth2.0 并非是一個(gè)認(rèn)證的協(xié)議，而是一個(gè)授權(quán)的協(xié)議，即無法用來認(rèn)證使用者的身份，而是在知道使用者身份以后來頒發(fā)對(duì)于該使用者的權(quán)限。
OAuth開始于2006年11月，當(dāng)時(shí)布萊恩·庫克正在開發(fā)Twitter的OpenID實(shí)現(xiàn)。與此同時(shí)，社交書簽網(wǎng)站Ma.gnolia需要一個(gè)解決方案允許使用OpenID的成員授權(quán)Dashboard訪問他們的服務(wù)。這樣庫克、克里斯·梅西納和來自Ma.gnolia的拉里·哈爾夫（Larry Halff）與戴維·雷科爾頓會(huì)面討論在Twitter和Ma.gnolia API上使用OpenID進(jìn)行委托授權(quán)。但他們討論得出結(jié)論，認(rèn)為OpenID沒有完成API訪問委托的開放標(biāo)準(zhǔn)。2007年4月，成立了OAuth討論組，這個(gè)由實(shí)現(xiàn)者組成的小組撰寫了一個(gè)開放協(xié)議的提議草案。來自Google的德維特·克林頓獲悉OAuth項(xiàng)目后，表示他有興趣支持這個(gè)工作。2007年7月，團(tuán)隊(duì)起草了最初的規(guī)范。隨后，Eran Hammer-Lahav加入團(tuán)隊(duì)并協(xié)調(diào)了許多OAuth的稿件，創(chuàng)建了更為正式的規(guī)范。
2007年10月, OAuth核心1.0最后的草案發(fā)布了。2008年11月，在明尼阿波利斯舉行的互聯(lián)網(wǎng)工程任務(wù)組第73次會(huì)議上，舉行了OAuth的BoF討論將該協(xié)議納入IETF做進(jìn)一步的規(guī)范化工作。這個(gè)會(huì)議參加的人很多，關(guān)于正式地授權(quán)在IETF設(shè)立一個(gè)OAuth工作組這一議題得到了廣泛的支持。2010年4月，OAuth 1.0協(xié)議發(fā)表為RFC 5849，一個(gè)非正式RFC。2012年10月，OAuth 2.0發(fā)布，正式發(fā)表為RFC 6749。OAuth 2.0是OAuth協(xié)議的下一版本，但不向下兼容OAuth 1.0。OAuth 2.0關(guān)注客戶端開發(fā)者的簡(jiǎn)易性，同時(shí)為Web應(yīng)用、桌面應(yīng)用、手機(jī)和智能設(shè)備提供專門的認(rèn)證流程。
Facebook的新的Graph API只支持OAuth 2.0，Google在2011年3月也宣布Google API對(duì)OAuth 2.0的支持，越來越多的互聯(lián)網(wǎng)應(yīng)用開始支持OAuth2.0。
云時(shí)代的OIDC
OpenID Connect是一種基于OAuth2.0規(guī)范的互操作認(rèn)證協(xié)議，旨在提供身份驗(yàn)證、授權(quán)服務(wù)所需的關(guān)鍵功能。它使用簡(jiǎn)單的REST/JSON消息流，其設(shè)計(jì)目標(biāo)是“使簡(jiǎn)單的事情變得簡(jiǎn)單和復(fù)雜的事情成為可能”。與任何先前的身份協(xié)議相比，開發(fā)人員集成起來是更加容易。
OpenID+OAuth 2.0=OpenID Connect
OpenID Connect允許開發(fā)人員跨網(wǎng)站和應(yīng)用程序驗(yàn)證用戶，而無需擁有和管理密碼。它允許所有類型的客戶端（包括基于瀏覽器的JavaScript和移動(dòng)應(yīng)用程序）啟動(dòng)登錄流，并接收有關(guān)登錄用戶身份的可驗(yàn)證斷言。
Oauth2.0授權(quán)服務(wù)器能夠?qū)τ脩暨M(jìn)行身份驗(yàn)證，但該框架也沒有提供一種標(biāo)準(zhǔn)的方法來將經(jīng)過身份驗(yàn)證的用戶的身份安全地傳遞給應(yīng)用程序。OIDC為這一需求提供了解決方案。OIDC被設(shè)計(jì)為OAuth2.0協(xié)議之上的一個(gè)層，以標(biāo)準(zhǔn)格式向應(yīng)用程序提供有關(guān)經(jīng)過身份驗(yàn)證的用戶的身份的信息。這為用戶身份驗(yàn)證和API授權(quán)的應(yīng)用程序提供了一個(gè)解決方案。
Google、PayPal和Yahoo等廣泛使用的社交媒體/服務(wù)提供商實(shí)現(xiàn)了OIDC，為面向消費(fèi)者的身份驗(yàn)證服務(wù)提供了解決方案，但協(xié)議中沒有任何內(nèi)容將其限制在面向消費(fèi)者的場(chǎng)景中。事實(shí)上，OIDC的設(shè)計(jì)可以同時(shí)面向消費(fèi)者用戶和企業(yè)員工的場(chǎng)景。
OIDC為用戶、應(yīng)用程序開發(fā)人員和身份提供者提供了好處。網(wǎng)站開發(fā)人員可以將實(shí)現(xiàn)身份驗(yàn)證和密碼重置邏輯的工作委托給OIDC提供者。用戶從中受益，因?yàn)樗麄兛梢岳靡粋€(gè)帳戶登錄到多個(gè)站點(diǎn)，而無需向其他站點(diǎn)公開其帳戶憑據(jù)。用戶擁有更少的用戶名和密碼來管理和享受單點(diǎn)登錄。如果OIDC支持能夠吸引更多的用戶使用他們的平臺(tái)，OIDC提供商可能會(huì)從中受益。OIDC提供了在SAML2.0中很有吸引力的Web單點(diǎn)登錄的優(yōu)點(diǎn)，同時(shí)與OAuth2.0結(jié)合，又讓它提供了兼具身份驗(yàn)證和現(xiàn)代應(yīng)用程序所需的API授權(quán)的解決方案。
可以預(yù)見，隨著微服務(wù)、云原生的迅猛發(fā)展，OIDC的應(yīng)用將會(huì)越來越廣泛。
過去十多年中身份的協(xié)議不斷演進(jìn)和修改，才成為今天的標(biāo)準(zhǔn)和規(guī)范，在演進(jìn)的過程中，這些協(xié)議被無數(shù)開發(fā)者仔細(xì)檢查過是否存在缺陷，所以比起自定義的流程，它們更加的安全，不太可能有漏洞。同時(shí)，遵循這些規(guī)范，也能增加了互操作性，與他人兼容，更符合方便用戶的視角。
當(dāng)然，這些協(xié)議因?yàn)槭褂帽姸?，很容易找到?duì)應(yīng)的SDK或者開發(fā)包，為開發(fā)者節(jié)約更多的時(shí)間。
