不同應(yīng)用場(chǎng)景選錯(cuò)身份驗(yàn)證協(xié)議的后果很嚴(yán)重，因?yàn)殄e(cuò)誤的身份驗(yàn)證協(xié)議會(huì)破壞安全架構(gòu)基礎(chǔ)，并限制未來(lái)擴(kuò)展。那么，常見(jiàn)的身份驗(yàn)證用例都有哪些推薦協(xié)議呢?

[[311793]]

身份驗(yàn)證系統(tǒng)無(wú)論安裝在內(nèi)部，還是托管在外部，都需要謹(jǐn)慎選擇合適的身份驗(yàn)證協(xié)議。符合您用例的正確協(xié)議，可以使整個(gè)系統(tǒng)安全高效運(yùn)行，并且驅(qū)動(dòng)未來(lái)擴(kuò)展和兼容各種標(biāo)準(zhǔn)。此外，若想使用戶身份可被外部服務(wù)識(shí)別，還需考慮如何在保證過(guò)程安全的情況下，便于這些服務(wù)攝入用戶身份數(shù)據(jù)。

身份驗(yàn)證指的是通過(guò)某種方式識(shí)別用戶身份，授權(quán)資源訪問(wèn)。本文所討論的身份驗(yàn)證協(xié)議包括 SAML 2.0、OpenID Connect (OIDC) 和 OAuth2。注意，OAuth2 并非身份驗(yàn)證協(xié)議，但因其使用廣泛，可使用戶通過(guò) Facebook、亞馬遜等社交服務(wù)提供商登錄，而納入討論。

身份、身份驗(yàn)證和授權(quán)協(xié)議。

這三個(gè)協(xié)議在功能上常有重疊。

• 身份協(xié)議提供關(guān)于用戶的信息，比如永久標(biāo)識(shí)符、電話或電子郵件地址，可用作該用戶登錄您系統(tǒng)的長(zhǎng)期標(biāo)識(shí)，從而驗(yàn)證該用戶并授權(quán)資源訪問(wèn)。SAML 和 OIDE 是最常見(jiàn)的例子。
• 身份驗(yàn)證協(xié)議未必需要個(gè)人標(biāo)識(shí)符。比如說(shuō)，Kerberos 系統(tǒng)就基于透明匿名密鑰交換，密鑰本身不包含標(biāo)識(shí)數(shù)據(jù)。
• OAuth2 和 UMA 等身份驗(yàn)證協(xié)議提供的方法，無(wú)需資源擁有者共享憑證，即可獲得受保護(hù)資源的訪問(wèn)權(quán)限。此類協(xié)議的一個(gè)重要方面是交互式用戶許可。OAuth2 協(xié)議常用于臨時(shí)身份和身份驗(yàn)證，使用標(biāo)識(shí)符等 OAuth2 過(guò)程中返回的用戶數(shù)據(jù)。

由于其靈活性，身份協(xié)議在政府、企業(yè)和消費(fèi)領(lǐng)域越來(lái)越常用，作為身份驗(yàn)證的最佳實(shí)踐方法，廣泛應(yīng)用于 Web、移動(dòng)應(yīng)用和桌面應(yīng)用程序。這些協(xié)議可能被用于單點(diǎn)登錄 (SSO) 應(yīng)用，需注意 OAuth2 相關(guān)問(wèn)題。

去中心化身份

說(shuō)到身份驗(yàn)證，不得不提 DID(或稱自主身份)。這種身份系統(tǒng)依賴用戶存儲(chǔ)在移動(dòng)設(shè)備上的身份屬性，使用分布式賬本技術(shù)驗(yàn)證這些屬性的持有情況。當(dāng)前，將這些系統(tǒng)與成熟標(biāo)準(zhǔn)身份協(xié)議集成的建議不斷提出，現(xiàn)狀就是復(fù)雜自定義協(xié)議，比如 uPort。因此，目前不推薦在通用身份或身份驗(yàn)證用例中使用 DID。不過(guò)，Avoco Secure 等提供的編排 API，倒是有望通過(guò)轉(zhuǎn)譯為標(biāo)準(zhǔn)協(xié)議而跨越這個(gè)障礙。

四大身份驗(yàn)證用例協(xié)議推薦

1. 物聯(lián)網(wǎng)設(shè)備及相關(guān)應(yīng)用

此用例中，應(yīng)用采用數(shù)字身份控制對(duì)應(yīng)用及應(yīng)用相關(guān)云資源的訪問(wèn)，比如說(shuō)，亞馬遜 Alexa 等物聯(lián)網(wǎng)設(shè)備。Alexa 用于創(chuàng)建數(shù)據(jù)存儲(chǔ)賬戶，然后從中共享數(shù)據(jù)。

協(xié)議選擇：OIDC/OAuth2

這是個(gè)授權(quán)訪問(wèn)資源的簡(jiǎn)單用例，OAuth2 就很合適，尤其是考慮到智能設(shè)備使用相對(duì)簡(jiǎn)單的情況，比如無(wú)鍵盤或屏幕的智能設(shè)備。

2. 消費(fèi)者身份提供商 (IdP)

需向依賴方 (RP) 提供身份數(shù)據(jù)的在線銀行或政府服務(wù)歸屬該類用例。IdP 持有敏感數(shù)據(jù)，用戶屬性通過(guò)所謂了解客戶 (KYC) 過(guò)程驗(yàn)證，提供達(dá)到標(biāo)準(zhǔn)水平的身份。僅受許可的 RP 能夠訪問(wèn) IdP。

協(xié)議選擇：SAML、OIDC

SAML 適用于安全要求高的場(chǎng)合。RP 和 IdP 之間的交換都能被雙方數(shù)字簽署和驗(yàn)證。這就保障了雙方身份的真實(shí)性，防止出現(xiàn)某一方被假冒的情況。此外，還可以加密來(lái)自 IdP 的斷言，以便不僅僅依賴 HTTPS 防止攻擊者觸及用戶的數(shù)據(jù)。若想進(jìn)一步夯實(shí)安全性，還可以定期輪轉(zhuǎn)簽名和加密密鑰。

OIDC 若要達(dá)到相同的安全水平，需要額外的加密密鑰，如開(kāi)放銀行 (Open Banking)擴(kuò)展中呈現(xiàn)的那樣，其設(shè)置和維護(hù)可能相對(duì)較繁瑣。但是，OIDC 得益于 JSON 的使用，相對(duì) SAML 更容易為移動(dòng)應(yīng)用所用。

3. 醫(yī)療數(shù)據(jù)共享門戶

該用例中，此門戶需支持高敏感醫(yī)療數(shù)據(jù)的多種數(shù)據(jù)共享方式。

協(xié)議選擇：OIDC、UMA

此處相對(duì)合適的選項(xiàng)是 OIDC，因?yàn)榭赡苌婕岸喾N設(shè)備，其中有些不是基于瀏覽器的，也就排除掉了 SAML。與 OIDC 關(guān)聯(lián)的內(nèi)置許可強(qiáng)化了數(shù)據(jù)共享的隱私性。此外，還可運(yùn)用簽名和加密增強(qiáng)安全性，達(dá)到處理此類數(shù)據(jù)所需的合規(guī)要求。

4. 支持身份服務(wù)大環(huán)境中多服務(wù)提供商的系統(tǒng)

保險(xiǎn)服務(wù)協(xié)會(huì)就是該用例的一大樣本。系統(tǒng)需向用戶提供使用現(xiàn)有身份賬戶連接這些服務(wù)的方式。用戶可能需要添加所需附加數(shù)據(jù)。

協(xié)議選擇：OIDC、OAuth2 和 SAML

用戶應(yīng)能選擇一家 IdP，以便已經(jīng)在不同 IdP 處擁有賬戶的用戶可以方便操作。舉個(gè)例子，有些用戶可能持有政府頒發(fā)的身份;其他用戶可能僅擁有亞馬遜賬戶或淘寶賬戶。

賦予用戶不同賬戶類型的選擇，可以使用戶無(wú)需先經(jīng)歷在線注冊(cè)和驗(yàn)證過(guò)程，就能很方便地訪問(wèn)各保險(xiǎn)服務(wù)。但這就要求每個(gè) RP 支持多個(gè)協(xié)議，并需處理一家提供商的身份可能不支持全部所需主張或?qū)傩缘膯?wèn)題。而解決方案就是使用身份編排代理，或采用能夠翻譯 RP 所需協(xié)議和收集全部所需屬性的代理服務(wù)。

【本文是51CTO專欄作者“李少鵬”的原創(chuàng)文章，轉(zhuǎn)載請(qǐng)通過(guò)安全牛（微信公眾號(hào)id:gooann-sectv）獲取授權(quán)】

戳這里，看該作者更多好文