詳解三種不同的身份驗證協(xié)議

本文最初發(fā)布于devever.net網(wǎng)站，經(jīng)原作者授權(quán)由InfoQ中文站翻譯并分享。

現(xiàn)在，身份驗證協(xié)議的數(shù)量快趕上應(yīng)用程序協(xié)議，結(jié)果，這個領(lǐng)域很容易讓人困惑。

最容易把人搞糊涂的是，很少有人注意到這樣一種事實：

存在許多不同種類的身份驗證協(xié)議，它們還試圖扮演完全不同的角色。

與往常一樣，首先請記住，身份驗證和授權(quán)是不一樣的功能。考慮到這一點，本質(zhì)上存在三種不同的身份驗證協(xié)議類別：

客戶端到應(yīng)用程序（客戶端身份驗證協(xié)議）
應(yīng)用程序到驗證服務(wù)器（后端身份驗證協(xié)議）
單點登錄（客戶端到驗證服務(wù)器到多個應(yīng)用程序）

客戶端到應(yīng)用程序的身份驗證協(xié)議由客戶端發(fā)送給應(yīng)用程序服務(wù)器進(jìn)行身份驗證。這種協(xié)議完全不揭示應(yīng)用程序服務(wù)器在幕后如何使用客戶端提供的信息對其進(jìn)行身份驗證。

應(yīng)用程序到驗證服務(wù)器的協(xié)議被應(yīng)用程序服務(wù)器用來將客戶端的身份驗證委托給某個服務(wù)器，該客戶端已使用客戶端到應(yīng)用程序的協(xié)議提供了信息，而驗證服務(wù)器可以更好地執(zhí)行身份驗證決策。這種協(xié)議允許將身份驗證處理外包給專門的身份驗證服務(wù)器，并且無需讓身份驗證數(shù)據(jù)庫對所有應(yīng)用程序服務(wù)器都開放訪問權(quán)限。

客戶端的身份驗證狀態(tài)（例如通過客戶端到應(yīng)用程序的協(xié)議）通過單點登錄服務(wù)器驗證后，一臺服務(wù)器使用單點登錄協(xié)議與另一臺服務(wù)器通信。換句話說，它們被用來傳遞身份驗證決策。客戶端先前成功通過驗證服務(wù)器的身份驗證的事實，可以在該客戶端和應(yīng)用程序服務(wù)器之間安全地傳輸。某些協(xié)議不需要進(jìn)一步干預(yù)或需要單點登錄服務(wù)器可用，即可允許客戶端在初始登錄后對應(yīng)用程序進(jìn)行身份驗證，而其他協(xié)議則需要。

單點登錄協(xié)議實際上包含兩個協(xié)議：“客戶端到驗證服務(wù)器”部分和“客戶端到應(yīng)用程序”部分。客戶端到驗證服務(wù)器部分可能是定制的，有時可能是非常普通的客戶端到應(yīng)用程序的身份驗證協(xié)議。而客戶端到應(yīng)用程序部分必須取決于SSO協(xié)議的設(shè)計。

客戶端到應(yīng)用程序協(xié)議

在客戶端到應(yīng)用程序驗證協(xié)議的范疇內(nèi)，存在驗證框架和驗證方法。驗證框架是一種可擴(kuò)展的框架，它允許實施任意多種驗證方法，并允許它在客戶端和應(yīng)用程序服務(wù)器之間動態(tài)協(xié)商使用哪種驗證方法。

一些身份驗證框架已集成到特定的應(yīng)用程序協(xié)議中。還有一些通用設(shè)計旨在被集成到任意多個應(yīng)用協(xié)議中。這樣甚至將來出現(xiàn)的應(yīng)用程序協(xié)議也可以利用框架中已經(jīng)定義的所有身份驗證方法，以及這些方法的庫實現(xiàn)。

客戶端到應(yīng)用程序的身份驗證框架：SASL

這類框架中可能最流行的是IETF的SASL。SASL沒有定義特定的有線編碼（這部分由應(yīng)用程序負(fù)責(zé)），而是從本質(zhì)上定義了身份驗證方法名稱（例如PLAIN、LOGIN、MD5等）的名稱空間，以及協(xié)商它們的過程。實際的方法特定協(xié)議已經(jīng)執(zhí)行，但是應(yīng)用程序協(xié)議僅需要促成不透明二進(jìn)制字符串序列的來回交換，直到身份驗證成功或失敗為止。

簡而言之，實現(xiàn)SASL的應(yīng)用程序協(xié)議僅需要提供以下機(jī)制：

服務(wù)器將支持的方法名稱（字符串）列表發(fā)送到客戶端的一種途徑
客戶端發(fā)送其要使用的方法名稱的途徑
客戶端將不透明的二進(jìn)制字符串發(fā)送到選定的SASL方法的一種途徑（可以由應(yīng)用程序服務(wù)器不透明地輸入到SASL庫中）
服務(wù)器的SASL庫將不透明的二進(jìn)制字符串發(fā)送到客戶端的一種途徑（可以不透明地反饋回客戶端的SASL庫）
驗證成功或失敗的一種通信途徑

如何提供這些機(jī)制取決于應(yīng)用程序協(xié)議，該協(xié)議必須定義一些適當(dāng)?shù)挠芯€協(xié)議。盡管特定的編組和狀態(tài)機(jī)是特定于應(yīng)用程序協(xié)議的，但是SASL方法本身就足夠獨立于應(yīng)用程序協(xié)議，因此實現(xiàn)各種SASL方法的通用SASL庫被廣泛采用。

一些最受歡迎的SASL方法是：

PLAIN，以明文形式提供身份驗證用戶名和密碼（以及可選的授權(quán)用戶名，可能與身份驗證用戶名不同）；
LOGIN，棄用的方法，它是提供純文本用戶名和密碼的另一種方法；
EXTERNAL，使客戶端完全不提供任何信息（可選的授權(quán)用戶名除外），并且是客戶端從連接上下文請求對其進(jìn)行身份驗證的一種方式。例如，如果連接使用帶有客戶端證書的TLS，并且客戶端證書足以滿足身份驗證的目的，則可以使用此方法進(jìn)行身份驗證；或者也能用于僅通過客戶端IP地址對其進(jìn)行身份驗證的情況；
ANONYMOUS，請求未經(jīng)身份驗證的訪問；
CRAM-MD5和DIGEST-MD5是質(zhì)詢響應(yīng)身份驗證方案，它們試圖避免傳輸未經(jīng)加密的密碼；
NTLM，windows NT LAN Manager身份驗證機(jī)制；
GSSAPI，是指主要用于促成Kerberos身份驗證的API（參見下文）。

如今，人們通常會使用SASL方法（例如PLAIN或LOGIN），這些方法通過安全通道（例如TLS）以明文形式傳輸密碼。

客戶端到應(yīng)用程序的身份驗證框架：HTTP

HTTP定義自己的身份驗證框架，并具有自己的方法集。可以說，HTTP避免SASL的原因在于其無狀態(tài)性和SASL不太相稱。由于HTTP設(shè)計的運行機(jī)制是讓客戶端發(fā)送單個請求塊，然后由服務(wù)器發(fā)送單個響應(yīng)，因此HTTP協(xié)議不適用于SASL設(shè)想的身份驗證完成之前的來回數(shù)據(jù)交換。

此外，對于每個請求都必須重復(fù)這種交換。

服務(wù)器通過發(fā)送一個401 Authorization Required錯誤，和WWW-Authenticate標(biāo)頭來請求身份驗證以訪問資源。該標(biāo)頭包含：

所需的身份驗證方法；
“域名稱”，提供對身份驗證域的描述；
必須為給定方法指定的其他參數(shù)。與SASL不同，一般來說一臺給定服務(wù)器只有一個方法（雖說HTTP RFC確實允許服務(wù)器通過發(fā)送多個WWW- Authenticate標(biāo)頭來支持多個方法，每個方法一個標(biāo)頭，但這種情況很少見）。然后，客戶端使用包含相同方法名稱和方法特定身份驗證數(shù)據(jù)的Authorization標(biāo)頭重新發(fā)出其請求。（請注意，HTTP使用術(shù)語authorization-授權(quán)，而不是authentication-身份驗證。）

一些常見的HTTP身份驗證方法有：

Basic（基本），以純文本形式指定用戶名和密碼；
Digest（摘要），指定一個用戶名并以質(zhì)詢-響應(yīng)模式哈希密碼；
Negotiate（協(xié)商），允許使用GSSAPI，并實質(zhì)上在HTTP身份驗證內(nèi)稱為SPNEGO的GSSAPI之上，重新實現(xiàn)了SASL風(fēng)格的方法協(xié)商模式。因為它涉及來回交換，所以可能需要多個請求，直到身份驗證成功為止。Windows通常將“Negotiate/SPNEGO”用于NTLM或Kerberos身份驗證。

客戶端到應(yīng)用程序的身份驗證框架：SSH

SSH還使用一組可擴(kuò)展的方法定義了自己的身份驗證框架。最常用的方法有：

keyboard-interactive（交互式鍵盤），通過任意終端提示登錄；
public-key（公鑰），客戶端證明其握有指定私鑰；
gssapi，通過Kerberos登錄（參見下文）。

客戶端到應(yīng)用程序的身份驗證方法：策略

客戶端到應(yīng)用程序的身份驗證方法通常可以分為幾個基本的類別：

完全遵循上下文身份驗證（例如TLS客戶端證書或IP地址身份驗證）（例如SASL EXTERNAL）。
以明文形式發(fā)送用戶名和密碼，其中安全性（如果有的話）由封裝的安全通道提供，并且在任何情況下，應(yīng)用程序服務(wù)器最終以明文形式獲得密碼（例如SASL PLAIN；HTTP Basic；SSH keyboard- interactive）。
質(zhì)詢-響應(yīng)方案，其中服務(wù)器發(fā)出質(zhì)詢隨機(jī)數(shù)，客戶端將密碼哈希或其他構(gòu)造應(yīng)用于隨機(jī)數(shù)和密碼來響應(yīng)質(zhì)詢（例如SASL CRAM-MD5）。

如今這些策略都已經(jīng)過時了，首先是由于人們常結(jié)合使用TLS與純文本傳輸，其次是因為它們傾向于避免以哈希形式在服務(wù)器上存儲密碼，或者要求以與驗證方案相關(guān)的特定方式對密碼進(jìn)行哈希處理。這樣的話，密碼哈希方法就會和身份驗證方法高度耦合。

非對稱密碼方案，其中客戶端在不傳輸私鑰的情況下證明其擁有私鑰（例如SSH public-key；TLS客戶端證書）。
Shared-secret（共享秘密）方案，例如TLS-PSK。
零知識證明方案，例如SRP。這些加密方式整潔但很少使用，并且還是會將身份驗證協(xié)議與服務(wù)器上哈希密碼的方法緊密耦合。
單點登錄協(xié)議的客戶端到應(yīng)用程序部分。

應(yīng)用程序到身份驗證服務(wù)器

另一類身份驗證協(xié)議與客戶端到應(yīng)用程序的身份驗證協(xié)議完全無關(guān)，而是應(yīng)用程序到身份驗證服務(wù)器的協(xié)議，或稱后端協(xié)議。后端驗證協(xié)議是在應(yīng)用程序服務(wù)器和驗證服務(wù)器之間使用的（而不是在要驗證的實體和對其進(jìn)行驗證的實體之間做一個協(xié)議），以便驗證客戶端提供的驗證細(xì)節(jié)。

這些協(xié)議經(jīng)常用于網(wǎng)絡(luò)訪問場景中，其中“應(yīng)用程序”服務(wù)器是網(wǎng)絡(luò)設(shè)備，如路由器、交換機(jī)或Wi-Fi接入點。由于我們不希望網(wǎng)絡(luò)中的每個Wi-Fi接入點都保留身份驗證數(shù)據(jù)庫的副本，因此后端協(xié)議允許將身份驗證決策外包給一個中心化授權(quán)源。因此，后端協(xié)議必須與某種客戶端到應(yīng)用程序的身份驗證協(xié)議結(jié)合使用：在客戶端和應(yīng)用程序之間使用客戶端到應(yīng)用程序協(xié)議，在應(yīng)用程序和身份驗證服務(wù)器之間使用后端協(xié)議。

流行的后端身份驗證協(xié)議包括RADIUS及其后繼者DIAMETER，它們主要用于網(wǎng)絡(luò)訪問場景（例如撥號Internet身份驗證、Wi-Fi身份驗證等）。由于這些協(xié)議原本設(shè)計用于支持網(wǎng)絡(luò)訪問場景，它們都屬于“AAA”（同時支持身份驗證、授權(quán)、計費）協(xié)議。例如，如果需要，它們的計費功能可對撥號Internet連接進(jìn)行基于時間和使用量的準(zhǔn)確計費。

盡管LDAP不是為后端身份驗證協(xié)議設(shè)計的，但它有時也被當(dāng)成身份驗證協(xié)議來用。應(yīng)用程序服務(wù)器可以嘗試向LDAP服務(wù)器進(jìn)行身份驗證來驗證用戶憑據(jù)。這種方法還有一個優(yōu)點是，如果成功，則應(yīng)用程序服務(wù)器還可以使用LDAP檢索有關(guān)用戶的信息。

應(yīng)用程序到身份驗證服務(wù)器：關(guān)聯(lián)的客戶端到應(yīng)用程序協(xié)議

RADIUS和DIAMETER這樣用于網(wǎng)絡(luò)訪問場景的后端驗證協(xié)議，傳統(tǒng)上設(shè)計用于和特定的客戶端到應(yīng)用程序驗證協(xié)議結(jié)合使用，比如由PPP定義的那些。PPP是一個OSI第2層協(xié)議，支持通過串行線路和撥號調(diào)制解調(diào)器發(fā)起IP網(wǎng)絡(luò)連接。PPP定義了自己的可擴(kuò)展身份驗證框架，并支持以下方法：

PAP，以明文形式傳輸用戶名和密碼；
CHAP，一種質(zhì)詢響應(yīng)方法（避免以明文形式傳輸密碼，但存在前文所述的質(zhì)詢響應(yīng)方法的缺點）；
MS-CHAP和MS-CHAPv2，CHAP的Microsoft變體；
EAP，可擴(kuò)展身份驗證協(xié)議，現(xiàn)代的首選協(xié)議。

EAP本身是一個身份驗證框架，定義了一組可擴(kuò)展的身份驗證方法，這意味著與PPP一起使用時，方法協(xié)商分為兩個級別：首先要協(xié)商EAP，然后必須協(xié)商一個特定的EAP方法。人們認(rèn)為EAP與其他PPP身份驗證協(xié)議不同，前者設(shè)計同時用于PPP和其他網(wǎng)絡(luò)訪問上下文（例如Wi-Fi身份驗證或以太網(wǎng)802.1x身份驗證）。（802.1x是對以太網(wǎng)的擴(kuò)展，可以根據(jù)成功的EAP身份驗證來確定網(wǎng)絡(luò)訪問權(quán)限）。

EAP和SASL之間有一些相似之處，因為它們都是支持可擴(kuò)展方法集的通用框架。但是，EAP定義了一個特定的有線協(xié)議，而SASL沒有定義。此外，EAP旨在支持網(wǎng)絡(luò)訪問應(yīng)用程序，而SASL旨在支持應(yīng)用程序級別的身份驗證應(yīng)用程序。

但是，關(guān)于EAP的最重要的一點是，它從一開始就被設(shè)計為可被應(yīng)用程序服務(wù)器不透明地經(jīng)隧道傳輸。例如，假設(shè)你通過調(diào)制解調(diào)器撥入路由器，并建立PPP連接。路由器必須了解協(xié)議（例如PAP或CHAP），并且知道如何通過RADIUS或DIAMETER與后端服務(wù)器交互協(xié)議。

在現(xiàn)代應(yīng)用程序中，例如Wi-Fi客戶端對一個WLAN接入點發(fā)送EAP，接入點只會將EAP消息作為不透明數(shù)據(jù)，然后將其在RADIUS或DIAMETER會話中通過隧道傳輸?shù)揭粋€網(wǎng)絡(luò)身份驗證服務(wù)器上，讓網(wǎng)絡(luò)身份驗證服務(wù)器來處理EAP消息。身份驗證服務(wù)器同樣可以返回封裝在RADIUS或DIAMETER會話中的EAP消息，Wi-Fi接入點將其解包并傳遞給客戶端。這樣，網(wǎng)絡(luò)設(shè)備就與所使用的身份驗證方法無關(guān)，并且不需要升級就能支持新的身份驗證方法。只有驗證服務(wù)器和客戶端需要升級。

請注意，客戶端永遠(yuǎn)不會發(fā)送RADIUS或DIAMETER。RADIUS和DIAMETER是嚴(yán)格的后端協(xié)議。因為EAP消息始終在轉(zhuǎn)發(fā)到身份驗證服務(wù)器之前被封裝在RADIUS或DIAMETER消息中（身份驗證客戶端無法控制的進(jìn)程），所以RADIUS或DIAMETER消息可以包括與EAP無關(guān)的，身份驗證服務(wù)器感興趣的客戶端信息消息本身。例如，如果客戶端正在為啟用802.1x的以太網(wǎng)端口發(fā)起驗證，則交換機(jī)可以包含關(guān)于客戶端連接到哪個端口的信息，并且身份驗證服務(wù)器可以預(yù)見它在這上面的決策。

單點登錄協(xié)議

現(xiàn)在，我們討論最復(fù)雜，最有趣的身份驗證協(xié)議：單點登錄協(xié)議。如前所述，單點登錄協(xié)議必須包括兩個部分：用于驗證客戶端到驗證服務(wù)器的協(xié)議，以及用于驗證客戶端到任意應(yīng)用程序服務(wù)器的協(xié)議。前者可能是標(biāo)準(zhǔn)的客戶端到應(yīng)用程序協(xié)議，也可能是定制的協(xié)議。而SSO協(xié)議的性質(zhì)要求后者是SSO協(xié)議所特有的，并且是任何SSO協(xié)議的核心。

單點登錄協(xié)議：非Web

SSO協(xié)議可以大致分為Web和非Web SSO協(xié)議。最受歡迎的非Web SSO協(xié)議是Kerberos。

Kerberos允許客戶端使用定制的身份驗證協(xié)議向身份驗證服務(wù)器發(fā)起身份驗證；客戶端會收到一個票證，該票證能以密碼方式向應(yīng)用程序服務(wù)器發(fā)起身份驗證，而無需與Kerberos身份驗證服務(wù)器之間進(jìn)一步的通信（驗證服務(wù)器在用戶登錄后可能會關(guān)閉，并且不會立即讓所有應(yīng)用程序無法訪問）。

該協(xié)議還支持客戶端來驗證服務(wù)器，以及服務(wù)器來驗證客戶端。如今，*nix和Windows Active Directory環(huán)境都使用Kerberos。對于客戶端到應(yīng)用程序的身份驗證，通常不直接在身份驗證框架內(nèi)將其實現(xiàn)為身份驗證方法。

相反，它通常是通過GSSAPI調(diào)用的，并且是主要的用法，例如SASL GSSAPI方法、HTTP Negotiate（GSSAPI）身份驗證方法和SSH GSSAPI身份驗證方法。

有趣的是，Kerberos的當(dāng)前版本Kerberos 5于1993年發(fā)布，因此僅依賴對稱加密，避免了對非對稱加密的依賴。如果Kerberos是今天設(shè)計的，則它可能會使用公鑰加密，并且對中心化身份驗證服務(wù)器的依賴會稍少一些。

不幸的是，Web的極速增長看來已經(jīng)侵蝕了所有非web協(xié)議（無論是身份驗證還是其他用途）的發(fā)展空間。（但Kerberos 5仍然是安全的。）

單點登錄協(xié)議：Web

對于Web SSO協(xié)議，客戶端到身份驗證服務(wù)器協(xié)議一直是標(biāo)準(zhǔn)的Web形式，也就是表單-cookies形式。客戶端到應(yīng)用程序服務(wù)器的身份驗證協(xié)議卻很特殊。

通常，當(dāng)應(yīng)用程序服務(wù)器希望對客戶端進(jìn)行身份驗證時，它將通過HTTP重定向?qū)⒖蛻舳艘騍SO身份驗證服務(wù)器。如果客戶端尚未通過中心化驗證，則會要求它進(jìn)行驗證；否則，如果客戶端已經(jīng)完成單點登錄，則流程將繼續(xù)進(jìn)行而無需用戶干預(yù)。

在對用戶完成身份驗證之后，身份驗證服務(wù)器會通過另一個HTTP重定向?qū)⒖蛻舳艘氐綉?yīng)用程序服務(wù)器。返回請求包含從身份驗證服務(wù)器傳輸?shù)綉?yīng)用程序服務(wù)器的身份驗證信息，以建立客戶端的憑據(jù)。該數(shù)據(jù)本身將以某種方式進(jìn)行身份驗證，以防止客戶端對其修改。由于信息從身份驗證服務(wù)器到應(yīng)用程序服務(wù)器的傳遞是通過客戶端進(jìn)行的，因此客戶端就像是攜帶花粉的蜜蜂。在某些SSO實現(xiàn)中，應(yīng)用程序服務(wù)器可以直接回調(diào)身份驗證服務(wù)器，以驗證它已通過客戶端接收到的信息。在其他SSO實現(xiàn)中，通過客戶端從身份驗證服務(wù)器傳遞到應(yīng)用程序服務(wù)器的信息是加密保護(hù)的，不需要進(jìn)一步驗證。

應(yīng)當(dāng)注意，上文不是對特定SSO協(xié)議的描述，而是對所有常用技術(shù)的概括。由于Web應(yīng)用程序僅需要符合標(biāo)準(zhǔn)的Web瀏覽器，因此對在Web平臺之上實現(xiàn)的協(xié)議進(jìn)行標(biāo)準(zhǔn)化的要求較少，于是出現(xiàn)了許多專有的Web SSO實現(xiàn)。

但一些標(biāo)準(zhǔn)還是出現(xiàn)了。今天流行的標(biāo)準(zhǔn)有：

SAML2，安全性斷言標(biāo)記語言第2版，一種XML的誤用，用于表達(dá)加密簽名語句，語句中包含受驗證方和驗證用途的信息，并在域之間傳遞此類語句。它很流行，受AWS for SSO支持。
OAuth，一種基于HTTP的協(xié)議，用于促成網(wǎng)站之間的授權(quán)流。它側(cè)重于授權(quán)而非驗證，但是現(xiàn)在也經(jīng)常用于驗證，尤其是與OpenID Connect擴(kuò)展一起使用時。它很流行，受AWS for SSO支持。OpenID Connect擴(kuò)展添加了身份驗證功能，并允許在身份驗證期間將用戶信息（例如電子郵件地址等）傳遞到網(wǎng)站。（請注意，OpenID Connect是一種位于OAuth之上的技術(shù)，與OpenID 2沒有任何關(guān)系。）

曾經(jīng)被廣泛采用，但現(xiàn)在已經(jīng)過時的協(xié)議包括：

OpenID2，一種Web SSO協(xié)議，它使人們可以驗證對特定URL的控制。（請注意，這與基于OAuth構(gòu)建的OpenID Connect無關(guān)，兩者適用的用例差異巨大。）
LID，一種Web SSO協(xié)議，與OpenID 2類似，是OpenID 2的同期競爭對手，但是不太流行。

本地API

最后我們討論一些系統(tǒng)本地身份驗證API。這些不是協(xié)議，但與協(xié)議關(guān)系很近。

PAM

PAM（可插入身份驗證模塊）是nix領(lǐng)域中本地身份驗證的事實標(biāo)準(zhǔn)。它在linux上普遍用于本地身份驗證，并且在其他nix操作系統(tǒng)上也很流行。PAM提供了基于插件的身份驗證功能；PAM插件是動態(tài)鏈接庫，可以在運行時加載以提供任意身份驗證邏輯。使用何種PAM插件由系統(tǒng)配置確定，因此可以根據(jù)需要重新配置PAM。

盡管PAM具有高度可擴(kuò)展性，但它被設(shè)計為支持終端交互式登錄應(yīng)用程序，因此受到了限制。PAM模塊向用戶提交一系列零個或多個交互式提示（例如“Password：”），因此不能支持Kerberos那樣的SSO身份驗證方法（盡管有的PAM模塊可以提示用戶輸入Kerberos密碼并執(zhí)行初始Kerberos登錄）。

雖然PAM主要是為了支持終端交互式登錄而設(shè)計的，但將PAM用作某些應(yīng)用程序協(xié)議的后端（例如，用作SASL PLAIN的后端）也是可行且普遍的。但是，這要求應(yīng)用程序服務(wù)器理解（或正確猜測）PAM模塊發(fā)出的線路提示的語義。例如，Dovecot IMAP服務(wù)器假定，如果PAM模塊要求輸入沒有字符回顯的行，則說明它要求輸入密碼；如果該模塊要求輸入一行啟用了字符回顯的內(nèi)容，則它是在要求用戶名。因此，雖然PAM模塊可以被編寫為支持通過TOTP硬件密鑰進(jìn)行身份驗證，并在終端上提示輸入六位數(shù)的值，但非終端應(yīng)用程序（例如SASL應(yīng)用程序）無法支持它，除非專門設(shè)計為支持這種模塊的提示。

GSSAPI

GSSAPI是另一個本地API，具有正式標(biāo)準(zhǔn)。它設(shè)計用于網(wǎng)絡(luò)應(yīng)用程序（而不是終端交互），并且最常用于通過Kerberos SSO啟用身份驗證。實際上，盡管它是旨在擴(kuò)展到任意身份驗證方案的通用API，但它幾乎只被用于Kerberos、SPNEGO和NTLM應(yīng)用程序。可以通過SASL GSSAPI方法，通過任何SASL應(yīng)用程序使用GSSAPI。

原文鏈接：

https://www.devever.net/~hl/auth