这里似乎有两个不同的问题：关于访问令牌和关于大角色列表。

访问令牌

OAuth2被设计成能够处理高负载，这需要一些权衡。特别是这就是为什么OAuth2一方面明确区分“资源服务器”和“授权服务器”角色，另一方面明确区分“访问令牌”和“刷新令牌”的原因。如果对于每个请求，您都必须检查用户授权，这意味着您的授权服务器应该能够处理系统中的所有请求。对于高负载系统，这是不可行的。

OAuth2允许您在性能和安全性之间进行以下权衡：授权服务器生成一个访问令牌，资源服务器可以在不访问授权服务器的情况下对其进行验证（在授权服务器的生命周期内完全或至少不超过一次）。这实际上是授权信息的缓存。因此，通过这种方式，您可以大大减少授权服务器的负载。与缓存一样，缺点也是一样的：授权信息可能会停止。通过改变访问令牌的生命周期，您可以调整性能与安全平衡。

如果您使用微服务架构，其中每个服务都有自己的存储并且不访问彼此的存储，这种方法也可能会有所帮助。

但是，如果您没有太多负载并且只有单个资源服务器，而不是使用不同技术实现的大量不同服务，则没有什么可以阻止您对每个请求进行实际的全面验证。即是的，您可以将访问令牌存储在数据库中，在每次访问资源服务器时对其进行验证，并在删除用户时删除所有访问令牌等。但正如@Evk注意到的那样，如果这是您的场景 - OAuth2 对您来说是一个超调。

角色大列表

AFAIU OAuth2没有为用户角色提供明确的特性。有一个“作用域”特性也可以用于角色，它的典型实现会产生250个角色的太长的字符串。OAuth2仍然没有为访问令牌明确指定任何特定的格式，所以您可以创建一个自定义令牌，将角色信息作为位掩码保存。使用base-64编码，您可以在一个字符中包含6个角色(64 = 2^6).所以250-300个角色可以用40-50个字符来管理。

JWT公司

由于您可能无论如何都需要一些自定义令牌，因此您可能会对JSON Web令牌（又名JWT）感兴趣。简而言之，JWT 允许您指定自定义附加有效负载（专用声明）并将您的角色位掩码放在那里。

如果您真的不需要任何 OAuth2 高级功能（例如作用域），您实际上可以单独使用 JWT，而无需完整的 OAuth2 内容。尽管 JWT 令牌应该仅通过内容进行验证，但您仍然可以将它们存储在本地数据库中，并对数据库进行其他验证（就像您将对访问刷新令牌所做的那样）。

更新2017年12月1日

如果您要使用OWIN OAuth基础结构，您可以通过< code > oauthbeareratuthenticationoptions 和< code > OAuthAuthorizationServerOptions 中的< code>AccessTokenFormat自定义令牌格式。您也可以覆盖< code>RefreshTokenFormat。

下面是一个草图，展示了如何将角色声明“压缩”为单个位掩码：

1. 定义列出您拥有的所有角色的自定义角色枚举

[Flags]
public enum CustomRoles
{
    Role1,
    Role2,
    Role3,

    MaxRole // fake, for convenience
}

    public static string EncodeRoles(IEnumerable<string> roles)
    {
        byte[] bitMask = new byte[(int)CustomRoles.MaxRole];
        foreach (var role in roles)
        {
            CustomRoles roleIndex = (CustomRoles)Enum.Parse(typeof(CustomRoles), role);
            var byteIndex = ((int)roleIndex) / 8;
            var bitIndex = ((int)roleIndex) % 8;
            bitMask[byteIndex] |= (byte)(1 << bitIndex);
        }
        return Convert.ToBase64String(bitMask);
    }

    public static IEnumerable<string> DecodeRoles(string encoded)
    {
        byte[] bitMask = Convert.FromBase64String(encoded);

        var values = Enum.GetValues(typeof(CustomRoles)).Cast<CustomRoles>().Where(r => r != CustomRoles.MaxRole);

        var roles = new List<string>();
        foreach (var roleIndex in values)
        {
            var byteIndex = ((int)roleIndex) / 8;
            var bitIndex = ((int)roleIndex) % 8;
            if ((byteIndex < bitMask.Length) && (0 != (bitMask[byteIndex] & (1 << bitIndex))))
            {
                roles.Add(Enum.GetName(typeof(CustomRoles), roleIndex));
            }
        }

        return roles;
    }

public class CustomTicketSerializer : IDataSerializer<AuthenticationTicket>
{

    public const string RoleBitMaskType = "RoleBitMask";
    private readonly IDataSerializer<AuthenticationTicket> _standardSerializers = DataSerializers.Ticket;

    public static SecureDataFormat<AuthenticationTicket> CreateCustomTicketFormat(IAppBuilder app)
    {
        var tokenProtector = app.CreateDataProtector(typeof(OAuthAuthorizationServerMiddleware).Namespace, "Access_Token", "v1");
        var customTokenFormat = new SecureDataFormat<AuthenticationTicket>(new CustomTicketSerializer(), tokenProtector, TextEncodings.Base64Url);
        return customTokenFormat;
    }

    public byte[] Serialize(AuthenticationTicket ticket)
    {
        var identity = ticket.Identity;
        var otherClaims = identity.Claims.Where(c => c.Type != identity.RoleClaimType);
        var roleClaims = identity.Claims.Where(c => c.Type == identity.RoleClaimType);
        var encodedRoleClaim = new Claim(RoleBitMaskType, EncodeRoles(roleClaims.Select(rc => rc.Value)));
        var modifiedClaims = otherClaims.Concat(new Claim[] { encodedRoleClaim });
        ClaimsIdentity modifiedIdentity = new ClaimsIdentity(modifiedClaims, identity.AuthenticationType, identity.NameClaimType, identity.RoleClaimType);
        var modifiedTicket = new AuthenticationTicket(modifiedIdentity, ticket.Properties);
        return _standardSerializers.Serialize(modifiedTicket);
    }

    public AuthenticationTicket Deserialize(byte[] data)
    {
        var ticket = _standardSerializers.Deserialize(data);
        var identity = ticket.Identity;
        var otherClaims = identity.Claims.Where(c => c.Type != RoleBitMaskType);
        var encodedRoleClaim = identity.Claims.SingleOrDefault(c => c.Type == RoleBitMaskType);
        if (encodedRoleClaim == null)
            return ticket;

        var roleClaims = DecodeRoles(encodedRoleClaim.Value).Select(r => new Claim(identity.RoleClaimType, r));
        var modifiedClaims = otherClaims.Concat(roleClaims);
        var modifiedIdentity = new ClaimsIdentity(modifiedClaims, identity.AuthenticationType, identity.NameClaimType, identity.RoleClaimType);
        return new AuthenticationTicket(modifiedIdentity, ticket.Properties);
    }
}

var customTicketFormat = CustomTicketSerializer.CreateCustomTicketFormat(app);
OAuthBearerOptions.AccessTokenFormat = customTicketFormat;
OAuthServerOptions.AccessTokenFormat = customTicketFormat;

在＜code＞OAuthAuthorizationServerProvider＜/code＞中添加＜code＞ClaimTypes。分配给用户的每个角色的角色到ClaimsIdentity

在控制器中使用标准的< code>AuthorizeAttribute，例如

[Authorize(Roles = "Role1")]
[Route("")]
public IHttpActionResult Get()

为了方便和一些安全，您可以子类 AuthorizeAttribute 类以接受 CustomRoles 枚举而不是字符串作为角色配置。

我希望我回答对了你的问题，并能提供一些答案:

1） 如果您开发的AS要求在每次用户登录时进行验证，则可以将其兑现。

2）我认为@Hans Z.的意思是由AS撤销用户。当RS撤销用户时，它不会改变他们仍然是AS识别的用户的事实。但是当AS撤销用户时，它会阻止他们使用他们的身份。

3） 本文可能假设授权是由 RS 完成的，AS 只负责告诉您谁是用户，RS 将据此决定授权。

刷新令牌方法的主要优点是减少数据库查询的数量，访问令牌具有声明和签名，因此无需查询数据库即可信任令牌。

缓存访问令牌将起作用，但随后您必须查询每个请求的缓存。

您必须在访问权限更改的n分钟延迟和检查访问令牌有效性的查询数量之间进行权衡

随着复杂性的增加，您几乎可以实现这两个目标。在这种情况下，您必须将缓存存储在服务器RAM中，并且只存储已撤销的令牌以保持列表较小。当您有多个服务器实例时，您将不得不在您的RS和AS之间保持已撤销令牌的缓存同步，这会带来复杂性。

基本上，当访问令牌被撤销时，AS必须通知所有RS将该访问令牌添加到撤销的令牌缓存中。

每当有资源请求时，RS会检查令牌是否被撤销，如果没有撤销，RS会服务器资源。这样，每个请求都有开销，但由于缓存在内存中，因此开销大大减少，撤销令牌的数量将比有效令牌的数量少得多。