IdentityServer的范围和声明设计

翻译文章

Scope and claims design in IdentityServer

IdentityServer的范围和声明设计

前言：

我经常看到开发人员对IdentityServer中范围和声明的关系感到困惑。希望这篇博客文章会有所帮助。

在OpenID Connect和OAuth 2.0中，scope 的定义是客户端应用程序试图访问的资源。
资源的概念故意含糊不清，并且两个不同的规范将scope的概念用于两个相似但完全不同的用途，加剧了混淆。此外，设计scope取决于应用程序开发人员，这意味着您必须在scope内赋予语义，
这需要一定数量的计划和(或者)设计。

OpenID Connect 和 Identity Scopes

鉴于OpenID Connect全部与应用程序对用户身份验证有关，那么scope（作为资源）意味着该应用程序需要有关用户的身份数据。例如，用户的唯一ID，名称，电子邮件，员工ID或其他类似的行。此scope是一种身份资源，并且是应用程序对用户要求的一些声明(cliams)的别名。

OpenID Connect规范定义了一些scope，例如，openid仅映射到用户的唯一ID（或子声明sub claim），而配置文件则映射到大约10多个声明(claims)，其中包括用户的名字，姓氏，显示名称，网站，位置等等。自定义身份scope (Custom identity scopes)是允许的，并且可以说，scope的范围是由应用程序开发人员定义的。因此，可以定义一个名为employee_info的自定义scope，该scope可以代表员工ID，建筑物编号和办公室编号。

在IdentityServer中，这些identity scopes 是使用IdentityResource类建模的。构造函数允许您传递scope的名称（例如employee_info）和一个字符串数组，该字符串数组是该socpe表示的声明的列表。

new IdentityResource("employee_info", new[] {
    "employee_id", "building_number", "office_number"})

由IdentityResources类及其嵌套类（如OpenId，Profile等）提供OpenID Connect规范定义的scope（和相应的声明）。

var identityResources = new [] { 
    new IdentityResources.OpenId（），
    new IdentityResources.Profile（），
};

该设计的一个不错的方面是，仅在需要时才将权利要求交付给应用程序，如所请求的范围所表示的，并且不同的应用程序可以通过请求不同的范围来接收不同的权利要求。

OAuth 2.0和 API Scope

鉴于OAuth 2.0就是要允许客户端应用程序访问API，因此作用域仅仅是API的抽象标识符。范围可以像“日历API”或“文档存储API”一样粗粒度，也可以像“对日历API的只读访问权限”或“对日历API的读写访问权限”一样细粒度。也可能将其他语义也注入到您的范围定义中。此范围是API范围，它对应用程序使用API​​的能力进行建模。

在IdentityServer中，这些API范围是使用ApiResource类建模的。构造函数允许您传递范围的名称（例如日历或文档）。

var apiResources = new [] { 
    new ApiResource（“ calendar”），
    new ApiResource（“ documents”），
};

用于调用这些API的访问令牌将包含最少的声明集。这些声明中的一些是协议声明（例如，范围，颁发者，到期等），并且存在一个与用户相关的主要声明，即用户的唯一ID（或子声明）。如果在一个API中需要有关用户的其他声明，则ApiResource构造函数将提供一个附加的构造函数参数作为字符串数组，该字符串数组是所需声明的列表。从本质上讲，这允许ApiResource类对API以及该API所需的用户声明进行建模。

var apiResources = new [] { 
    new ApiResource（“ calendar”，new [] {“ employee_id”}），
    new ApiResource（“ documents”，new [] {“ country”}），
};

此设计的一个不错的方面是，仅当要在那些API上使用访问令牌时，才在访问令牌中声明声明。

摘要

对于在OpenID Connect和OAuth 2.0协议中使用抽象作用域概念，以及同时允许一种具体的模式来表达应用程序和API需要哪些声明的方式，我们觉得这是一个很好的平衡。

希望这可以帮助到为此困惑的人。