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

[[311793]]

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

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

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

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

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

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

去中心化身份

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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