Logo Logo
GitHub Designed by Logto
authorization
在 GitHub 上编辑

访问控制 (Access control)

访问控制是限制谁可以在系统的某些资源上执行哪些操作。这是一种定义和执行访问策略的基本安全机制。

什么是访问控制 (Access control)？

访问控制涉及三个主要组成部分：

  • Subject (主体)：在资源上执行操作的实体。主体可以是用户、服务或设备。
  • Resource (资源)：受访问控制保护的实体。资源可以是文件、数据库、API 或任何其他数字资产。
  • Action (操作)：主体可以在资源上执行的操作。操作可以是读取、写入、执行或任何其他操作。

访问控制根据 主体 和 操作 对 资源 的访问进行选择性限制。

以下是一些访问控制的实际例子：

  • 在电子商务系统中，用户 (主体) 可以 阅读 (操作) 他们的订单 (资源)。
  • 在社交网络中，用户 (主体) 不能 删除 (操作) 其他用户的个人资料 (资源)。
  • 在微服务架构中，服务 (主体) 可以 写入 (操作) 数据到数据库 (资源)。

有时，在技术实现中会忽略资源，将访问控制定义为谁 (主体) 可以执行哪些操作的限制。例如，基本的 OAuth 2.0 框架仅通过使用 scopes (权限) 来指定操作，并未定义资源。

访问控制的支持可能因 授权服务器 (Authorization server) 或 身份提供者 (Identity provider, IdP) 而异。某些系统可能支持 OAuth 2.0 的资源指示符 ，这是一种扩展 OAuth 2.0 的机制，允许客户端指定他们想要访问的资源。

访问控制模型

对少数主体和资源进行限制的决策很简单，但不具备可扩展性。因此，行业开发了许多访问控制模型，以便有效管理。在 身份与访问管理 (Identity and access management, IAM) 的背景下，以下是一些常见的访问控制模型：

还有其他访问控制模型，如 基于策略的访问控制 (PBAC) 。每种模型都有其自身的优势和劣势，选择模型取决于你的用例和需求。

OAuth 2.0 中的访问控制

在 OAuth 2.0 的背景下，访问控制通常通过 scopes 来实现。通常，scope 的值是一个将资源和操作结合在一起的字符串。例如，read:orders 或 write:profile。

[!注意] 在大多数情况下，“scopes” 这个术语可以与 “permissions” 互换使用。

值得注意的是，OAuth 2.0 并未定义 scopes 的结构和含义。scopes 的解释留给 资源服务器 (Resource server) ，而 scopes 的签发留给 授权服务器 (Authorization server) 。

例如，用户 (主体) 需要访问他们在电子商务系统中的订单 (资源)。通过利用 OAuth 2.0，你可以定义一个 scope read:orders，并且一个 web 应用 (客户端) 将从授权服务器请求这个 scope。以下是一个简化的流程：

在此流程中，取决于技术架构，资源服务器可以是一个 API 服务，也可以是有能力访问资源 (订单) 的客户端 (web 应用) 自身。

资源指示符参数

尽管人们通常用资源和操作来定义 scopes（例如，read:orders，其中 orders 是资源，read 是操作），但当资源和操作的数量增加时，这种方法的可扩展性有限。RFC 8707 向 OAuth 2.0 引入了 resource 参数 (即 资源指示符 )，允许客户端指定他们想要访问的资源。

RFC 规定 resource 参数应为代表资源的 URI。例如，可以使用 https://api.example.com/orders 而不是简单地使用 orders。这种方法有助于防止命名冲突，并通过允许使用实际的资源 URL 来增强资源匹配的精确性。

授权服务器支持

OAuth 2.0 并未定义授权服务器应如何执行访问控制。它将实现细节留给授权服务器的自行决定。因此，授权服务器的选择可能极大地影响访问控制机制。例如，某些授权服务器可能支持资源指示符，而其他服务器则可能不支持。重要的是根据你的业务需求决定使用哪种访问控制模型，然后选择支持该模型的授权服务器。如果你不确定使用哪个访问控制模型， 基于角色的访问控制 (Role-based access control, RBAC) 对大多数情况来说已经足够好。

另请参阅