技術研究_單點登入(SSO)不同類型架構介紹_part2.SSO Protocols(SAML/OIDC)補充&OAuth 2.0



1.Secure Client-Side Credential Caching
(基於用戶端的單點登錄/安全的客戶端憑據緩存)

特性&優點:
  • 基於客戶端的SSO解決方案。
  • 所有與身份驗證相關的信息都保存在客戶端的憑據存儲中。
  • 只要用戶提供的憑據有效,就可以實現透明的身份驗證,用戶與其他應用程序服務器之間的互動更加方便。
  • 允許用戶只需要身份驗證一次後,對於後續請求的其餘信息將自動由系統提供,無需用戶干預。
缺點:
  • 缺乏靈活性,所有憑據都存儲在客戶端,可能會導致用戶在不同工作站上登錄時遇到問題。
  • 需要定期更新客戶端憑據緩存中的信息,尤其是在新增應用程序服務器時,管理和維護成本較高。
  • 不宜在便攜客戶端設備或存在安全問題的操作系統中使用,可能存在信息泄露風險。
  • 可能導致安全性方面的風險,因為緩存的憑據可能會被不當使用或盜取。

在 .NET C# 和 Java 各自可能會採用那些第三方整合solution,套件或是library?

.NET C#
  • Microsoft Identity:用於身份驗證和授權的完整解決方案,支持OAuth和OpenID Connect。
  • Auth0:一個靈活的身份驗證和授權平台,提供多種身份驗證協議支持。
  • IdentityServer4:開源的OpenID Connect和OAuth 2.0框架,專為ASP.NET Core設計。
Java
  • Spring Security:提供全面的身份驗證和授權支持,支持多種身份驗證協議。
  • Keycloak:一個開源身份和訪問管理解決方案,支持SAML、OAuth2和OpenID Connect。
  • Auth0:與.NET相同,Auth0也提供對Java的支持。
  • OpenID Connect (OIDC)





2.Secure Server-Side Credential Caching
(基於伺服器的單點登錄/安全的伺服器端憑據緩存)

特性&優點:
  • 所有的身份驗證詳情都存儲在一個中央存儲庫中,快取則存儲在伺服器端。
  • 管理所有不同密碼並將所需信息直接提供給請求應用程序的任務由中央伺服器完成。
  • 中央集中式管控,便於統一管理和維護
  • 簡化了憑證管理流程,減少了多點管理的複雜性。
  • 憑證快取存儲在伺服器端,減少了憑證洩露的風險。

缺點:
  • 中央存儲庫成為單點故障(SPOF,Single Point of Failure),如果伺服器出現問題,可能影響所有相關應用的憑證訪問,雞蛋全放在同一個籃子中。
  • 需要高可用性設計和備份策略來減少故障風險。
  • 憑證數據庫之間的同步需要可靠的機制,否則可能導致憑證不一致問題。如果同步不及時或出現故障,可能影響用戶的正常登錄和使用。
  • 需要在主要和次要身份驗證權限之間建立信任關係,這可能需要額外的配置和管理工作。
在 .NET C# 和 Java 各自可能會採用那些第三方整合solution,套件或是library?

.NET C#
  • Azure Active Directory (AAD):微軟的企業級身份服務,支持OAuth、OpenID Connect和SAML。
  • Okta:一個企業級身份和訪問管理平台,支持多種身份驗證協議。
  • WS-Federation:一種基於Web的身份驗證協議,適合與Active Directory整合。

Java
  • Keycloak:提供伺服器端SSO解決方案,支持SAML、OAuth2和OpenID Connect。
  • Okta:與.NET相同,Okta也提供對Java的支持。
  • CAS (Central Authentication Service):一個開源的SSO協議,專為Java應用設計。


SSO Protocols補充


OpenID Connect (OIDC)
屬於:基於用戶端的單點登錄
  • OpenID Connect 是 OpenID Foundation 在 2014 年發布的 OpenID Connect Core 1.0 中定義的一個身分認證協議。
  • 設計理念是以當時就已被廣為使用的 OAuth 2.0 的協議為基礎,再加上可以認證使用者的層次而成。
  • 常常用在「以 Facebook、Google、Line 帳號登入」的功能。
  • OAuth 2.0 (RFC 6749) 是 IETF 在 2012 年發布的一個為授權而設計的協議
  • OAuth 2.0 只是一個定義如何使用 Access Token 來授權的協議,內容是沒有提到如何去認證一個使用者的登入。
  • 在 OpenID Connect 中的 Client 有了一個新稱呼叫 Relying Party,Authorization Server 的新稱呼為 OpenID Provider。OpenID Provider除了可以發放 Access Token 外,同時也可以發放 ID Token。
  • OpenID Connect 中定義的 ID Token 採取了 JWS(JSON Web Signature, RFC 7515)的規格。
  • 收到這 ID Token 的服務即可以透過它的數位簽章確保此使用者的身分的正確性。



SAML (Security Assertion Markup Language)
安全斷言標記式語言
屬於:基於伺服器的單點登錄
  • 最早是在 2001 年時由 OASIS 安全服務技術委員會(Security Services Technical Committee,SSTC)所開發出來
  • 設計用於跨域安全地傳遞身份驗證和授權數據。
  • 適合企業內部應用和跨組織的身份驗證。
  • 資料的傳送是透過基於 XML 的協議完成的。
  • 而後在 2005 年,SAML 版本升級為 2.0,因此如今人們口中的 SAML 即是泛指 SAML 2.0。
  • 是指在身分識別資訊提供者(Identity Provider,IdP)與服務提供者(Service Provider,SP)之間傳送驗證以及授權資料的一種公開標準。
  • 通常在同一個網域底下的身分驗證是相對較容易的,可以透過網路工作階段(web session)或是 cookie 等技術來達成。由於 session 無法在跨網域或跨伺服器的情況下使用,並且跨網域使用 cookie 也存在非常高的風險,使得跨網域的身分驗證執行起來困難重重。SAML 便是一個解決這個問題的公開標準。






Ref:
Implementing SSO in Enterprise Applications Using OpenID Connect
https://www.encora.com/insights/implementing-sso-in-enterprise-applications-using-openid-connect

SAML 是什麼?淺談安全斷言標記式語言
https://hennge.com/tw/blog/what-is-saml.html

OpenID Connect 是什麼?
https://hennge.com/tw/blog/what-is-openid-connect.html

每當點選社群帳號登入,背後發生了什麼事?
https://petertc.medium.com/openid-connect-a27e0a3cc2ae

深入淺出 OpenID Connect (一)
https://shuninjapan.medium.com/%E6%B7%B1%E5%85%A5%E6%B7%BA%E5%87%BA-openid-connect-%E4%B8%80-8701bbf00958

OAuth2.0 vs OpenID Connect (OIDC) - What? Why? How?
https://www.c-sharpcorner.com/article/oauth2-0-and-openid-connect-oidc-core-concepts-what-why-how/

Identity Management: SAML vs. OAuth2 vs. OpenID Connect
https://www.linkedin.com/pulse/identity-management-saml-vs-oauth2-openid-connect-jad-karaki/

Implement OpenID Connect for OCI API Gateway
https://www.ateam-oracle.com/post/oidc-oci-api-gateway


留言

這個網誌中的熱門文章

何謂淨重(Net Weight)、皮重(Tare Weight)與毛重(Gross Weight)

Architecture(架構) 和 Framework(框架) 有何不同?_軟體設計前的事前規劃的藍圖概念

(2021年度)駕訓學科筆試準備題庫歸納分析_法規是非題