与简单检查用户 ID 相比，claim/role/policy 授权的技术优势是什么？

What's the technical advantage of claim/role/policy authorization as opposed to plain check of a user's ID?

我使用 Identity Server 并通过策略和角色保护端点。这些反映在我分发给客户的访问令牌中。今天，我得到的建议是不要保护这样的方法：

[Authorize(Policy = "Elevated"), HttpGet("metadata")]
public IActionResult GetTenantMetadata() { ... }

我们可以跳过 JWT 的 role 部分，只执行以下操作。

[Authorize, HttpGet("metadata")]
public IActionResult GetTenantMetadata() { ... }

然后，在 Startup.cs 中，我们将像这样注册一个自定义处理程序。

services.AddHttpContextAccessor();
services.AddTransient<IAuthorizationHandler, HeaderHandler>();

然后将根据令牌中的 sub 值在处理程序中执行实际的安全性。没有角色，没有范围，什么都没有。对我来说，让我承担很多责任来创建保护逻辑，而不是依赖 IDS 和比我聪明得多的人，这在直觉上似乎是不明智的。我见过的所有解决方案都使用声明和角色来处理安全问题。所以我的直觉告诉我这是个坏主意。

protected override Task HandleRequirementAsync(
        AuthorizationHandlerContext context,
        CustomRequirement requirement)
    {
        HttpRequest request = Accessor.HttpContext.Request;
        string param = request.Headers.SingleOrDefault(a => a.Key == "param1");
        string someAccess = dbContext.GetAccess(param, context.User.GetUserId());

        bool authorized = SomeEvaluation(param, someAccess);
        if (authorized) context.Succeed(requirement);
        else context.Fail();

        return Task.CompletedTask;
    }

然而，我无法激发我的选择（除了胆量和其他人的样本），所以最后，我不确定了。我很谦虚地理解，如果我不能解释为什么，那么也许我错了。

我用谷歌搜索了基于声明的安全性和角色策略安全性等，但我可以为建议的替代方案想出一个名称。因此，我没有找到任何 material 讨论此事。

这种自定义授权方法叫什么，它的advantage/caveat是什么？

它仍然是声明授权，只是不是一个好的/实用的：你只使用了sub声明。没有理由抛出 away/not 使用由受信任的身份提供者提供的完美声明。

首先，让客户端通过 header 发送用户 ID 存在 安全风险 。您怎么知道它是否未被篡改，并且用户没有假装是管理员？你不能，这就是为什么你要求 ID 提供商对用户进行身份验证并签署令牌 以进行身份​​验证。

其次，cherry-picking 用户 ID 并在运行时从数据库中获取其他用户声明或 API 可以工作，但并非总是可行（应用程序不保留用户数据/委托对第 3 方的身份验证）或可行（高流量应用程序，太多的数据库查找）。

要授权一项操作，您可以使用断言声明策略。但是对于更高级或命令式的检查，您可以选择执行 AuthorizationHandler 和命令式 allow/block 操作。
它对 resource-based 授权很有用，但如果您需要的声明已经在访问令牌中提供，那么单行代码就有点矫枉过正了。

更多信息