大家好，欢迎来到IT知识分享网。
有兴趣加深您对 OAuth、OpenID Connect 或 SAML 的了解吗？继续阅读以获得新的见解并了解标准之间的差异。花椒壳-愿您平安健康
强调安全的重要性并不是一个新概念。我们几乎每周都会听到新的安全漏洞、数据泄漏和其他安全故障。当然，其中只有一部分是由 Web 应用程序引起的，但这并不是减少保护它们的努力的原因。
今天，我将带您了解可用的三种最常见的安全协议。我将介绍它们的功能，比较它们，并建议何时以及为什么它们之一可能是最佳选择。花椒壳-愿您平安健康
我将首先解释两个最基本的安全概念之间的区别：Authentication和Authorization。
身份验证与授权
身份验证和授权的概念与用户及其访问特定资源的愿望有关。
- 身份验证 – 是向安全提供商证明我们身份的过程，因此我们有兴趣回答“你是谁？”这个问题。
- 授权——是关于证明我们需要角色/权限来访问特定资源，所以这里的问题是，“你能做什么？”
当我们开始比较协议时，这两个概念之间的含义差异至关重要。特别是在比较 OAuth 和 OpenID Connect 的情况下。
SAML 的详细信息
首先，SAML只是Security Assertion Markup Language的缩写。它被描述为用于在相关方（特别是身份提供者和服务提供者）之间交换身份验证和授权信息的开放标准。
它最初由OASIS安全服务技术委员会于 2002 年创建，是当今讨论的协议中最古老的一个。自 2002 年以来，SAML 有过两次更新，一次是 2003 年版本 1.1 的次要更新，以及 2005 年版本 2.0 的一次主要更新。至于现在，SAML 2.0 是 OASIS 采用的官方标准。
SAML 中有四个最重要的概念——其中大部分在 1.0 和 2.0 版本之间发生了重大变化：
- 安全断言——服务提供商用来做出访问控制决策的事实。它们是使用 XML 语法编写的。我们可以区分三种类型的此类事实：身份验证、属性和授权决策。
- 协议——描述某些 SAML 元素（包括断言）如何打包在 SAML 请求和响应元素中，并给出 SAML 实体在生成或使用这些元素时必须遵循的处理规则。最重要的 SAML 协议类型称为查询。与断言类似，还有三种类型的查询：身份验证、属性、授权决策。直到 SAML 2.0 增加和描述了 6 个新协议，查询是 SAML 指定的唯一协议。
- 绑定— SAML 协议消息到标准消息格式和/或通信协议的映射。例如，SAML SOAP 绑定指定 SAML 消息如何封装在 SOAP 信封中，SOAP 信封本身绑定到 HTTP 消息。SAML 1.1 仅指定了一种绑定，即 SAML SOAP 绑定，但 SAML 2.0 带来了一个全新的绑定规范，定义了 6 种不同的独立绑定
- 配置文件– 详细描述断言、协议和绑定如何协作以支持定义的用例。最重要的配置文件是 Web 浏览器 SSO 配置文件。除了概要文件的完整重构，旨在使它们更加灵活，SAML 2.0 还为我们提供了许多新的概要文件。
如您所见，不同版本的 SAML 协议之间存在一些重大变化。深入研究这个谜团，我们可以注意到这些变化旨在使 SAML 2.0 比 1.1 或 1.0 版本更灵活。此外，由于这些更改的范围，SAML 2.0 和 1.1 不兼容。
此外，自由联盟于 2003 年贡献了一个名为 Identity Federation Framework 的标准，目前在 1.2 版中。它被用作 SAML 2.0 的基础，但它们又不兼容。花椒壳-愿您平安健康
OAuth 的详细信息
OAuth或开放授权最初由IETF（互联网工程任务组）于 2010 年 4 月作为RFC 5849发布，是一种授权协议。它代表资源所有者为客户端提供对服务器资源的“安全委托访问”。它还指定了资源所有者授权第三方访问其服务器资源而无需提供凭据的过程。
2012 年 10 月，我们以RFC 6749的形式获得了 OAuth 的第一次重大更新，这就是 OAuth 2.0 的创建方式。当然，OAuth 2.0 和 1.0 不兼容，你没想到吧？
目前，OAuth 2.1 处于草案状态。
如今，该标准是最常见的标准，被 Facebook 或 Google 等公司使用。他们中的许多人将其用作唯一支持的授权协议，例如：自 2010 年 8 月 31 日以来，所有第三方 Twitter 应用程序都被要求 使用 OAuth，而 Facebook 的 Graph API 仅支持 OAuth 2.0。
OAuth 中有四个主要概念：
- 资源所有者——能够授予对受保护资源的访问权限的实体。当资源所有者是个人时，他们被称为最终用户。
- 资源服务器——托管受保护资源的服务器，能够使用访问令牌接受和响应受保护资源请求。
- 客户端– 代表资源所有者并在其授权下发出受保护资源请求的应用程序。
- 授权服务器——服务器在成功验证资源所有者并获得授权后向客户端发出访问令牌。
Authorization Server 和 Client 之间的交互和关系是 OAuth 中最重要的部分。
我今天要提到的最后一个协议是 OpenID Connect，它基于 OAuth 2.0。
OpenID Connect 的详细信息
或者OIDC基于 OAuth 2.0 规范的身份验证协议。而且，它是第三代名为OpenID的工具，它从未出名并被广泛使用。创建于 2014 年是当今最年轻的协议。
它的主要目标是“让简单的事情变得简单，让复杂的事情成为可能”。它允许客户端根据授权服务器执行的身份验证来验证最终用户的身份。此外，它公开了类似 REST 的 API，使我们能够获取有关最终用户的基本信息。
OpenID Connect 通过在 OAuth 授权请求中添加 OpenID 范围值来工作。有关执行的身份验证的信息作为 JWT 返回并称为 ID 令牌。OpenID 流程的两个最重要的构建块是：
- OpenID Providers (Ops) -> OAuth 2.0 Authentication Servers 实现 OpenID Connect
- 依赖方 (Rps) -> 使用 OpenID Connect 的 OAuth 2.0 客户端
作为旁注，我可以为您提供 OpenID Connect 的数学方程式：
（身份、认证）+ OAuth 2.0 = OpenID Connect
SAML、OAuth 和 OpenID Connect 之间的区别
-
最大的区别
SAML 主要看起来像是准备工作的工具，而 OAuth 和 OpenID Connect 更像是规范 – 描述特定流程 – 可以进一步实施。更重要的是，OpenID Connect 建立在 OAuth 之上，而 OAuth 本身和 SAML 是独立的。自然地，所有三种协议在任何组合中都不兼容。
这里的一个显着区别是 OAuth 规范似乎缺乏细节，并且在实施您的解决方案时留下了一些重要的主题。这可能会导致同一协议的实现不兼容，因此似乎不是一个特别好的主意。幸运的是，OpenID Connect 填补了其中的一些空白。花椒壳-愿您平安健康 目的
SAML 是用于在相关方之间交换身份验证和授权信息的标准。虽然 OAuth 旨在提供一种仅授权机制。尽管如此，在 OAuth 中，当我们滥用授权功能使身份验证成为可能时，我们也可以实现一种称为伪身份验证的东西。在某种程度上，这正是 OpenID Connect 正在做的事情，但规范和流程已更改为更安全且更少混淆。因为伪身份验证的确切描述超出了本文的范围，所以您可以在此处找到更多信息的页面。OpenID Connect 在现有 OAuth 规范上添加了一个身份验证层，有效地提供了身份验证和授权的可能性。
使用的复杂性
从我作为软件工程师的角度来看，SAML 看起来是使用和实现最复杂的，主要是因为老派的配置方法 – 编写 XML 文件以及与协议和绑定相关的所有事情。在 OpenID 和 OAuth 的情况下，您使用普通的旧 HTTP 而不是旧的 JWT。我知道现在我们有一切工具，但在某些情况下，您可能需要进行一些低级检查并相信我，在这种情况下您不想与自动生成的 XML 作斗争。另一方面，OAuth 本身不提供身份验证功能，因此您必须将其与其他协议混合使用，这是非常有问题的，或者使用伪身份验证——甚至更成问题。
显着特点
首先，所有三个协议似乎都专注于支持 SSO。我可以补充一点，SAML 是第一个（有史以来）提供跨域 SSO 的框架设计。此外，SAML 允许我们与 LDAP 等工具集成以“获取”已定义的用户配置文件。其余两个协议中不包含此功能。另一方面，SAML 似乎不是保护移动和SPA应用程序的最佳选择。事实上，SAML 最适合具有传统后端的老式应用程序。它以这种方式工作，主要是因为多年前这种应用程序类型不存在时做出的概念性决定。也许 SAML 3.0 如果它被创建（或何时）会在这里添加一些额外的可能性。
经过这个相当长的比较之后，我们可以开始解释特定协议何时以及为什么可能是最好的。
何时选择确切的协议
如果您希望我为每个案例都提供灵丹妙药的解决方案，那么不幸的是，您会感到失望。像往常一样，我会给你一些一般性的指导方针，并把最终决定权留给你。
首先，如果您的应用程序已经使用了 SAML，那么就去使用 SAML，任何其他的混合都会以令人头疼的方式结束。
如果您想与 Google、Facebook 或 Twitter 进行多次交互，那么 OAuth 和 OpenID 将是最合适的。请记住，如果您严重依赖授权，那么 OAuth 将是更好的解决方案，而 OpenID Connect 更适合身份验证密集型集成。
对于移动和 SPA 类型的应用程序，OpenID Connect 可能是最适合的协议。但是，如果您只想保护 API，那么 OAuth 2.0 可能是更好的选择。
总结
上面的指导方针是对今天文本的一个很好的总结。我尽量保持客观，不赞成任何特定的解决方案。我希望我为您提供了一些关于当今最常见的安全协议的额外知识，并且我的指南在某个时候会派上用场。选择一种工具来保护您的应用程序的最终决定由您决定。请记住仔细考虑这个决定，因为它可能不是最容易恢复的。感谢您的时间。
花椒壳-愿您平安健康花椒壳资源网,资源下载,主要提供个人搜集资源、设计素材、音乐、视频、图片等一切与互联网有关的资源https://www.xinliu.vip/
免责声明：本站所有文章内容,图片，视频等均是来源于用户投稿和互联网及文摘转载整编而成，不代表本站观点，不承担相关法律责任。其著作权各归其原作者或其出版社所有。如发现本站有涉嫌抄袭侵权/违法违规的内容,侵犯到您的权益，请在线联系站长,一经查实,本站将立刻删除。 本文来自网络,若有侵权，请联系删除，如若转载，请注明出处：https://haidsoft.com/151944.html
