• Home
  • home > tools > cloudServices > Azure >

    单点登录之身份验证与授权：CAS/OAuth/SAML/OpenID

    Author：zhoulujun Date：

    身份验证允许进入系统，而授权允许访问同一系统内的特定功能。从功能上讲，OAuth 用于访问授权，而 SAML 和 OpenID Connect 用于用户认证。OAuth2 仅用于授权而不用于身份验证，OIDC 用于对用户进行身份验证

    在介绍具体协议之前，有必要先说明“认证（Authentication）”和“授权（Authorization）”的区别。

    • 认证（Authentication）即确认该用户的身份是他所声明的那个人；

    • 授权（Authorization）即根据用户身份授予他访问特定资源的权限。

    身份验证允许进入系统，而授权允许访问同一系统内的特定功能。而认证与授权需要联合使用，才能让用户真正登入并使用应用系统。

    Authentication(又被称为AuthN，身份验证)，它指的是 the process of verifying that "you are who you say you are"，也就是说这个过程是为了证明你是你。通常来说有这么几个方式：

    • Single-factor - 也就是可以通过单一的因素证明”你是你“，比如密码、PIN码

    • Multi-factor - 有时候 Single-factor 没有办法保证”你是你“，就会需要一些多重验证的手段，比如动态口令、生物识别等

    上面提到的是两种用的比较多的手段，还有一些其他的，比如安全问题，短信，email认证等等

    Authorization(又被称为AuthZ，权限验证)，他指的是 the process of verifying that "you are permitted to do what you are trying to do"，也就是说这个过程是为了证明你是否拥有做这件事的权限，比如修改某个表格等等，如果没有权限的话通常会返回 403 错误码。

    安全断言标记语言 (SAML) 是一种开放标准，它试图弥合身份验证和授权之间的鸿沟。

    OAuth 是一个开放的授权标准。OpenID Connect 是在 OAuth 2.0 之上运行的身份验证标准。下面详细介绍这些标准的差异及其在身份验证和授权中的作用。

    什么是 SAML？

    SAML （Security Assertion Markup Language）是一种基于 XML 的标准，用于在 IdP（身份提供者） 和SP（服务提供商）之间交换身份验证和授权数据，以验证用户的身份和权限，然后授予或拒绝他们对服务的访问权限。

    SAML 术语

    • IdP——身份提供者

    • SP ——服务提供商

    • 用户——使用系统访问服务提供商服务的用户

    典型的 SAML 工作流由 IdP、SP 和用户组成。用户信息作为断言发送。

    SAML 1.0由结构化信息标准促进组织（OASIS）安全服务技术委员会于2002年11月推出，并宣布成为OASIS标准。

    SAML 2.0 于 2005 年推出，专门针对 Web 应用程序进行了优化，使信息能够通过 Web 浏览器传输。他不兼容1.x版本！

    让我们假设用户有一个 Idp 帐户并拥有有效的凭据

    v2-b081f54ff042b330347c595beada4a9d_720w.webp

    流程图如下

    SAML 将其留给身份提供者使用合适的身份验证方法，尽管它建议实施传输级安全性和消息级安全性。相反，该标准强制使用基于 XML 的消息在服务提供者和身份提供者之间传递信息。这些消息称为安全断言，可以是以下三种类型中的任何一种，即：

    • 身份验证语句：向服务提供者确认身份提供者已对主体进行身份验证的断言。

    • 属性声明：包含一个或多个属性或名称-值对，在此基础上授予主体访问权限。

    • 授权决策声明：一旦主体有权访问服务提供商提供的 Web 资源，就可以执行一项或多项操作的断言。

    SAML 故意限制各方可以使用 XML 断言执行的操作。基于 XML 的可扩展访问控制标记语言 (XACML) 可用于细粒度访问控制。

    SAML 如何工作？

    典型的 SAML 交换涉及委托人，通过 Web 浏览器或其他一些所谓的用户代理，尝试访问服务提供商的 Web 资源。

    • 服务提供者使用 Web 浏览器向身份提供者发送身份验证请求。

    • 身份提供者可以要求用户提供用户名或密码或两者。

    • 在验证用户身份后，身份提供者将身份验证声明连同用户凭证一起发送回服务提供者。

    • 根据来自身份提供者的消息，服务提供者允许或禁止用户尝试访问其服务。

    SAML 简化了联合身份验证和授权的实施，这涉及使用单个身份提供者跨多个组织和安全域的多个服务提供者。

    联合标识的一个示例是单点登录 (SSO)，SAML 已成为 SSO 的核心标准之一。SAML 使用身份提供者发送给服务提供者的称为断言（包含用户授权）的 XML 文档。

    什么是单点登录？

    单点登录 (SSO) 是用户可以使用一组凭据登录多个应用程序的过程。

    单点登录

    用户无需一遍又一遍地建立身份，只需对用户进行一次身份验证，然后就可以访问多个不同的服务和应用程序。

    SSO 的类型

    SSO 的类型

    提供 SSO 的标准和协议有很多，其中一些著名的是

    1. 安全访问标记语言 (SAML)

    2. 开放授权 (OAuth)

    3. 开放 ID 连接 (OIDC)

    4. Web 服务联合 (WS-Federation)

    5. Kerberos

    在 SAML 中，SSO 采用允许访问多个应用程序的浏览器会话 cookie 的形式。


    什么是 OAuth？

    OAuth 是一种开放式授权标准，通过访问令牌授予对应用程序、设备、应用程序编程接口 (API) 和服务器的安全委托访问权限。OAuth 授权应用程序访问您的数据，而无需授予它访问您的凭据的权限。

    在 OAuth 之前，HTTP 基本身份验证是获取系统访问权限的最常用形式，只需要使用用户名和密码。

    SSO 是在 SAML 流行时出现的，但 SAML 的问题在于它并不特别适合单页应用程序和现代 Web 应用程序，这些应用程序通过异步 JavaScript 和 XML (AJAX) 和 Web 服务对 API 进行后台 HTTP 调用。此外，SAML 也不适用于手机、智能电视和物联网。

    SAML 2.0于2005年被结构化信息标准组织（OASIS）批准实行。

    OAuth 是比 SAML 更新的标准，由 Google 和 Twitter 于 2006 年开始联合开发。它的开发部分是为了弥补 SAML 在移动平台上的不足，并且基于JSON而不是 XML。

    OAuth 使用 JSON 数据包和 API 调用，是现代 Web 的理想选择。

    OAuth2 术语

    OAuth2 仅用于授权而不用于身份验证

    • Authorization Server（授权服务器）：（例如：谷歌）

    • Resource Server（资源服务器）：（例如：Bitbucket）

    • Resource Owner（资源所有者）：使用系统从资源服务器访问服务的用户（例如：Bitbucket 用户）

    • Client: 请求访问服务访问的应用

    典型的 OAuth 工作流程涉及三个参与者，即用户、消费者和服务提供者。

    1. 工作流从用户向服务提供者展示执行涉及消费者的操作的意图开始。

    2. 消费者从服务提供者那里获得一个请求令牌和一个秘密，将它们交给用户，然后将用户重定向到服务提供者，以便前者可以使用后者显式地授权请求令牌。

    3. 然后服务提供者授予一个访问令牌，允许消费者代表用户访问受保护的资源。

    刷新令牌通常是长期存在的，可用于从服务提供商处获取新的访问令牌。另一方面，访问令牌是短暂的。

    20241021163704470474281.png

    上述是一个抽象的授权流程，而在具体实现中，在前三步中会有几个变种，即不同的授权模式，常见的授权模式包括:

    • Authorization Code Grant: 授权码模式，最为常用，最安全，强烈推荐；

    • Implicit Grant: 适用于SPA应用，已经不再推荐使用，被PKCE模式所替代；

    • Resource Owner Password Credentials Grant: 需要把用户的用户名和密码暴露给Client；

    • Client Credential Grant: 整个流程没有用户的概念，适用于服务端->服务端调用的场景。


    OAuth 不向后兼容早期的 OAuth 1.0a。OAuth 2.0 使用更广泛，尽管 OAuth 1.0a 上仍有一些。如果您正在考虑使用 OAuth，建议使用 OAuth 2.0。除了更容易实现之外，OAuth 2.0 的另一个优点是参与者之间传递的令牌在传输过程中被加密。

    什么是 OpenID Connect？

    OpenID Connect基于 OpenID分散式身份验证协议，在 OAuth 2.0 之上提供了一个身份验证层。它解决了 OAuth 中缺乏身份验证机制的问题，这在授权敏感交易（如支付）时是一个弱点。

    OIDC是基于OAuth2.0扩展出来的一个协议。除了能够OAuth2.0中的Authorization场景，还额外定义了Authentication的场景。

    v2-1f48b943ec6316cafd194a2b9fbddb90_720w.webp

    可以说OIDC协议是目前最主流的SSO标准协议，且对开发者友好，实现起来比较简单。

    典型的OpenID Connect工作流程涉及三方，即客户端、最终用户和身份提供者。

    • 客户端或依赖方将最终用户发送给身份提供者，最终用户在身份提供者处验证身份并授权对客户端的访问。

    • 身份提供者向客户端发送一个授权码，然后客户端使用它向身份提供者请求访问权和 ID 令牌。

    • 一旦客户端获得令牌，它就可以代表最终用户执行操作。

    OpenID Connect 使用签名且可加密验证的 JSON Web 令牌来确保访问和 ID 令牌在各方之间交换信息期间不被篡改。

    相比OAuth2，OIDC引入了id_token等和userinfo相关的概念：

    • 整个OAuth2协议，只是定义了access_token/refresh_token，但是这俩token只是为了保护Resource Server的，并没有Resource Owner的身份信息；

    • OIDC引入了id_token的概念，用这个特殊的token来表示这是Resource Owner的身份证：

      • 参考：https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims

      • 标准化id_token的格式：即大家熟知的JWT；

      • 标准化id_token的内容：Standard Claims

    • OIDC引入了关于如何获取详细userinfo的Endpoint；

    • OIDC定义了类似于SAML Metadata的Discovery接口，俗称well-known接口：

      • 参考：https://openid.net/specs/openid-connect-discovery-1_0.html

    OIDC协议的登陆授权流程和OAuth2.0基本类似, 整个流程的参与者也类似，只不过换了个术语：

    • OpenID Provider：简称OP，负责认证和授权

    • Relying Party：简称RP，OAuth 2.0中的Client

    hqsm06kqcv.png

    以下是 OAuth 2.0 抽象流程图

    7573af9c759ed71dd0a81953bfd51c73.webp



    什么是CAS？

    Central Authentication Service简称CAS，是一种常见的B/S架构的SSO协议。和其他任何SSO协议一样，用户仅需登陆一次，访问其他应用则无需再次登陆。

    顾名思义，CAS是一种仅用于Authentication的服务，它和OAuth/OIDC协议不一样，并不能作为一种Authorization的协议。

    当前CAS协议包括CAS 1.0、CAS2.0、CAS3.0版本，这三个版本的认证流程基本类似。

    CAS的认证流程通过包括几部分参与者:

    • Client: 通常为使用浏览器的用户

    • CAS Client: 实现CAS协议的Web应用

    • CAS Server: 作为统一认证的CAS服务器

    认证流程大致为: 

    CAS认证流程

    CAS协议是一个比较简陋单点登陆协议，协议本身比较轻量级也比较容易实现，但是能够解决的场景比较单一；

    市面上实现了CAS协议的应用并不多，笔者也不推荐这种协议，所以也不做多介绍


    OAuth、SAML 和 OpenID Connect 之间有什么区别？

    bgfc0oiml1.jpg

    虽然 OAuth、SAML 和 OpenID Connect 的用例多种多样，但从功能上讲，OAuth 用于访问授权，而 SAML 和 OpenID Connect 用于用户认证。因此，OAuth用于与 SAML 和 OpenID Connect截然不同的情况。它也可以与 SAML 或 OpenID Connect 一起使用。

    OAuth

    当您让应用程序（例如 Trello）访问您的 Gmail 联系人时，您可能使用了 OAuth。在这种情况下，您是用户，Trello 是消费者，Gmail 是服务提供者。Gmail 提供了允许 Trello 访问您的联系人的令牌。

    OpenID Connect

    对于 OpenID Connect，如果您使用 Facebook 或其他应用程序在另一个应用程序中验证了您的帐户，那么您可能已经使用过它。您登录身份提供商 Facebook 以访问第三方应用程序（例如 Spotify）。您可能已登录 Facebook，但您的凭据安全地存储在 Facebook 中，以防 Spotify 被黑客入侵时免受任何潜在威胁。

    SAML

    SAML 主要用于企业。许多组织使用它来将用户登录到内部网络。登录后，您无需输入凭据即可访问网络中的应用程序。

    将 OIDC 与 OAuth2 结合使用

    OAuth2 仅用于授权而不用于身份验证，OIDC 用于对用户进行身份验证

    OIDC 位于 OAuth 2.0 之上，以添加有关用户的信息并启用 SSO 流程。它允许跨多个应用程序使用一个登录会话。例如，如下所示，您可以使用社交媒体登录来访问应用程序，而无需在应用程序中创建帐户

    启用 OAuth2 和 OIDC 的示例登录页面

    v2-7f8c3f23950c56c6a684a7d0aadc2ad1_720w.webp

    OAuth2 流与 OIDC 集成

    v2-8adff5662f21fe650aff5bb18d7f8b3f_720w.webp

    上图解释了当您使用 Google 登录应用程序时发生的整个过程。步骤的数量可能看起来很复杂，但整个过程在几毫秒到几秒内结束。

    1. 用户进入 Bitbucket 页面登录

    2. 用户点击使用 Google 登录

    3. 浏览器将用户重定向到 Google 登录页面

    4. Google 显示凭据页面供用户输入凭据

    5. 用户输入谷歌凭据并点击提交

    6. Google 验证凭据并生成访问令牌并将其发送到浏览器

    7. 浏览器在Authorization Header中嵌入Access Token（Bearer Token），将用户的登录请求发送到BitBucket服务器

    8. Bitbucket 服务器将联系 Google 验证访问令牌并响应浏览器

    9. 现在用户登录到 Bitbucket 应用程序




    参考文章：

    OAuth 2.0 与 OpenID Connect 协议的完整指南  https://www.infoq.cn/article/euvhttyf3jmfakmm8cmn

    OAuth vs SAML vs OpenID：了解它们之间的差异 https://developer.aliyun.com/article/1080044

    单点登录 (SSO)：SAML、OAuth2、OIDC 简化 https://zhuanlan.zhihu.com/p/561676161

    单点登录协议有哪些？CAS、OAuth、OIDC、SAML有何异同？ https://cloud.tencent.com/developer/article/1727265

    过于详细！终于搞懂SSO里面的SAML和OIDC讲的啥了 https://zhuanlan.zhihu.com/p/312224113




    转载本站文章《单点登录之身份验证与授权：CAS/OAuth/SAML/OpenID》,
    请注明出处：https://www.zhoulujun.cn/html/tools/cloudServices/Azure/9291.html

    收藏
    上一篇：Microsoft Entra(Azure ADD) MSAL库SSO OAuth2登录详解
    下一篇：零信任架构：微软身份大管家Microsoft Entra