什么是授权服务器
认证和授权是应用开发过程中最基础、最重要的模块。
授权和访问策略的关系
授权与访问策略执行，共同的保障了正确的（人）实体能够访问到正确的资源方面，而非法的实体或非法的请求则被拒绝。为了更好的实现这一目标，我们从逻辑上进行了授权与访问策略执行的分离。即授权（通过某种形式，如 Token/Ticket）授予某一实体一定的权限，访问策略执行来检查实体持有响应的票据（Token/Tiket）的合法性来进行相应的允许或者拒绝访问被保护的资源。
举个例子来说，我们在入住酒店的时候，会在前台通过身份证的验证获取到房卡（类似于 token），这个房卡里包含了你可以进入的房间，可以消费的类型（餐厅、健身房）等权利。房间、餐厅、健身房的刷卡机会检查该房卡是否能够进入进行消费。
授权是在消费之间就已经确定的，在前台登记的那时，有前台人员录入相应的权限。访问的策略执行点一般在受保护资源内或最近的执行点进行执行，以免被绕过。
对授权和访问策略的的执行进行了逻辑上的分离。
相关术语
我们需要了解一些术语，以便能够理解 API 安全管理的规范：
- API 产品：具有一组 API 端点的应用程序这些端点可以有不同的需求和用例，但听同一个授权服务器来了解用户或服务可以做什么和不能做什么。它也是用户使用带有 ID 令牌的 OpenID Connect 登录的服务。
- Authorization server【授权服务器】: 授权服务器的核心是 OAuth 2.0 铸币机，利用 XAuth 的范围、声明和访问策略。您可以在 XAuth 中创建授权服务器，通常每个 API 产品一个服务器。授权服务器通常用于一个用例而不是一个端点。
- Scopes: 范围：范围是在您的 API 端点上执行的操作。它们内置在应用程序中或者统一的 API 网关中，并且使用设置声明和策略从授权服务器请求访问。
- Claims: 声明：声明是用于授权用户请求在应用程序中执行某些操作的语句。声明通常不会添加到 ID 令牌（ID Token）中，因为它用于进行身份验证。声明被添加到授权服务器基于范围和策略创建的访问令牌（Access Token）中。声明可以是通用的或基于 API 端点的自定义的特殊声明。例如，标准声明的示例：电子邮件、姓名或角色。对于您的自定义声明，您可能希望将自定义配置文件信息或组分配等特定详细信息添加到任一类型的令牌中。
- Tokens: 令牌：ID 和访问令牌的使用方式不同。ID 令牌携带有关用户的信息，用于使用 OpenID Connect 登录和访问系统。访问令牌是动态的，用于根据访问令牌内的授予范围获得对资源的访问权限。
- Payload: 有效负载：该信息与 API 调用一起发送到接收服务器，其中包含有关所需操作的附加信息。
典型的用例
OAuth2.0 最大的亮点是在 token 中包含了作用范围（标准中定义为 Scope），范围 Scope 可以在授权令牌中包含“指定的权限”，即作用范围可以指定用户权限（调用 API 的范围）。
以一个商店应用和管理后台的应用举例，比如，使用 Scope 为 LIST，用于在账单 API 中列出发票。使用 ProductManage 可以用户管理商品。
如果列出发票的 ID 被包含在 URL 或作为传递的参数，作为该 API 的请求参数。因此，可能会出现恶意越权的情况，即一个用户可以操纵篡改传递的权限参数以列出另一个用户的发票。而 Scope 包含在 Access Token 中，Token 定义的签名和加密机制则可以避免被恶意篡改的风险。
同时，开发者除了标准范围以外，也可以创建[自定义 Scope]用于自己开发的 API。范围可以根据开发者需求包含更多和授权相关的数据，以用于后续的 API 的授权，这比“ if”语句的编码方式要更为友好和优雅。
基于 Claims 进行更细粒度的控制
横向越权的风险
通过使用 Scope 可能避免了部分越权的风险，但还有可能出现横向越权的风险。比如，一个用户可以操纵篡改传递的 ID 参数以列出另一个用户的发票。
因此，仅仅使用范围是不够的，范围 Scope 锁定了客户端应用程序被允许做什么操作，但对于对特定用户被允许操作哪些数据没有帮助，因为它们只包含了参数的“名称”，而没有限定“值”。因此，还需要使用 Claims 来限定值。
例如，通过 Claims 来限定当前用户的 Id Token 的详细信息，以便于 API 的逻辑判断，当前用户是否在查询自己相关的数据，而不是查询其他人的数据。
XAuth 的授权服务器
XAuth 授权的服务作为一项独立的服务，客户端向授权服务器进行请求授权，将授权与业务进行分离，它定义了不同的流来获取令牌，客户端从而能够在不需要知道用户凭证的情况下授予对资源的访问权。通过这样做，我们解决上述所有问题。
通过访问策略的设置，可以根据请求的用户不同、应用不同，给出不同的 Access Token 和 Id Token，以满足不断变化的 API 访问控制的安全需求。
