别吃錯藥：四大身份驗證場景的協定選擇

雲栖号： https://www.aliyun.com/#module-yedOfott8 第一手的上雲資訊，不同行業精選的上雲企業案例庫，基于衆多成功案例萃取而成的最佳實踐，助力您上雲決策！

不同應用場景選錯身份驗證協定的後果很嚴重，因為錯誤的身份驗證協定會破壞安全架構基礎，并限制未來擴充。那麼，常見的身份驗證用例都有哪些推薦協定呢?

身份驗證系統無論安裝在内部，還是托管在外部，都需要謹慎選擇合适的身份驗證協定。符合您用例的正确協定，可以使整個系統安全高效運作，并且驅動未來擴充和相容各種标準。此外，若想使使用者身份可被外部服務識别，還需考慮如何在保證過程安全的情況下，便于這些服務攝入使用者身份資料。

身份驗證指的是通過某種方式識别使用者身份，授權資源通路。本文所讨論的身份驗證協定包括 SAML 2.0、OpenID Connect (OIDC) 和 OAuth2。注意，OAuth2 并非身份驗證協定，但因其使用廣泛，可使使用者通過 Facebook、亞馬遜等社交服務提供商登入，而納入讨論。

身份、身份驗證和授權協定。

這三個協定在功能上常有重疊。

• 身份協定提供關于使用者的資訊，比如永久辨別符、電話或電子郵件位址，可用作該使用者登入您系統的長期辨別，進而驗證該使用者并授權資源通路。SAML 和 OIDE 是最常見的例子。
• 身份驗證協定未必需要個人辨別符。比如說，Kerberos 系統就基于透明匿名密鑰交換，密鑰本身不包含辨別資料。

• OAuth2 和 UMA 等身份驗證協定提供的方法，無需資源擁有者共享憑證，即可獲得受保護資源的通路權限。此類協定的一個重要方面是互動式使用者許可。OAuth2 協定常用于臨時身份和身份驗證，使用辨別符等 OAuth2 過程中傳回的使用者資料。

  由于其靈活性，身份協定在政府、企業和消費領域越來越常用，作為身份驗證的最佳實踐方法，廣泛應用于 Web、移動應用和桌面應用程式。這些協定可能被用于單點登入 (SSO) 應用，需注意 OAuth2 相關問題。

去中心化身份

說到身份驗證，不得不提 DID(或稱自主身份)。這種身份系統依賴使用者存儲在移動裝置上的身份屬性，使用分布式賬本技術驗證這些屬性的持有情況。目前，将這些系統與成熟标準身份協定內建的建議不斷提出，現狀就是複雜自定義協定，比如 uPort。是以，目前不推薦在通用身份或身份驗證用例中使用 DID。不過，Avoco Secure 等提供的編排 API，倒是有望通過轉譯為标準協定而跨越這個障礙。

四大身份驗證用例協定推薦

1.物聯網裝置及相關應用

此用例中，應用采用數字身份控制對應用及應用相關雲資源的通路，比如說，亞馬遜 Alexa 等物聯網裝置。Alexa 用于建立資料存儲賬戶，然後從中共享資料。

協定選擇：OIDC/OAuth2

這是個授權通路資源的簡單用例，OAuth2 就很合适，尤其是考慮到智能裝置使用相對簡單的情況，比如無鍵盤或螢幕的智能裝置。

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

需向依賴方 (RP) 提供身份資料的線上銀行或政府服務歸屬該類用例。IdP 持有敏感資料，使用者屬性通過所謂了解客戶 (KYC) 過程驗證，提供達到标準水準的身份。僅受許可的 RP 能夠通路 IdP。

協定選擇：SAML、OIDC

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

OIDC 若要達到相同的安全水準，需要額外的加密密鑰，如開放銀行 (Open Banking)擴充中呈現的那樣，其設定和維護可能相對較繁瑣。但是，OIDC 得益于 JSON 的使用，相對 SAML 更容易為移動應用所用。

3.醫療資料共享門戶

該用例中，此門戶需支援高敏感醫療資料的多種資料共享方式。

協定選擇：OIDC、UMA

此處相對合适的選項是 OIDC，因為可能涉及多種裝置，其中有些不是基于浏覽器的，也就排除掉了 SAML。與 OIDC 關聯的内置許可強化了資料共享的隐私性。此外，還可運用簽名和加密增強安全性，達到處理此類資料所需的合規要求。

4.支援身份服務大環境中多服務提供商的系統

保險服務協會就是該用例的一大樣本。系統需向使用者提供使用現有身份賬戶連接配接這些服務的方式。使用者可能需要添加所需附加資料。

協定選擇：OIDC、OAuth2 和 SAML

使用者應能選擇一家 IdP，以便已經在不同 IdP 處擁有賬戶的使用者可以友善操作。舉個例子，有些使用者可能持有政府頒發的身份;其他使用者可能僅擁有亞馬遜賬戶或淘寶賬戶。

賦予使用者不同賬戶類型的選擇，可以使使用者無需先經曆線上注冊和驗證過程，就能很友善地通路各保險服務。但這就要求每個 RP 支援多個協定，并需處理一家提供商的身份可能不支援全部所需主張或屬性的問題。而解決方案就是使用身份編排代理，或采用能夠翻譯 RP 所需協定和收集全部所需屬性的代理服務。

原文釋出時間：2020-01-05

本文作者：安全牛

本文來自阿裡雲雲栖号合作夥伴“

51CTO

”，了解相關資訊可以關注“

”