IdentityServer4中OpenID Connect能否从客户端请求令牌而非内部生成？

Hey, great question—this is a common concern when working with IdentityServer4, and it’s totally aligned with best practices to separate identity authentication from authorization decisions. Let’s break down how to address this:

IdentityServer4’s core job is to act as an Identity Provider (IDP)—it confirms who the user is, not what they can access. You don’t need to store resource permissions directly in IdentityServer; instead, you can offload authorization logic to dedicated services, which fits perfectly with OIDC and OAuth2 design patterns.

1. Use Scopes as resource identifiers (not permission storage) #

Instead of storing granular user permissions in IdentityServer, define Scopes that represent high-level resource access (e.g., read:orders, write:user-profile). Here’s how this works:

• Configure Scopes in IdentityServer to map to your API/resources, but don’t tie them to specific user permissions.
• When a user authenticates, use a custom IProfileService to check if the user should get requested Scopes—this is where you’d call your own authorization system to validate access, rather than relying on IdentityServer’s internal storage.
• The issued Bearer Token will only include the approved Scopes and basic user identity claims, not detailed permission data.

2. Implement a dedicated authorization service #

For complex permission models (like role-based, attribute-based, or ABAC), build a separate authorization service that your resource servers can call:

• When a resource server receives a Bearer Token, first validate its signature using IdentityServer’s public key to confirm authenticity.
• Extract the user ID and Scopes from the Token, then send a request to your authorization service asking: “Can this user perform [action] on [resource]?”
• In ASP.NET Core, you can wrap this logic in a custom IAuthorizationHandler to integrate it seamlessly with the framework’s authorization pipeline.

3. Pull dynamic claims from your authorization system #

If you want to include permission-related claims in the Token (without storing them in IdentityServer), use a custom IProfileService to fetch claims from your external user/authorization database:

public class CustomProfileService : IProfileService
{
    private readonly IYourAuthorizationService _authService;

    public CustomProfileService(IYourAuthorizationService authService)
    {
        _authService = authService;
    }

    public async Task GetProfileDataAsync(ProfileDataRequestContext context)
    {
        // Get the user's unique ID from the authentication subject
        var userId = context.Subject.FindFirstValue(ClaimTypes.NameIdentifier);
        
        // Fetch permission claims from your external authorization service
        var userPermissions = await _authService.GetUserPermissionsAsync(userId);
        
        // Add these claims to the token that IdentityServer issues
        context.IssuedClaims.AddRange(userPermissions);
    }

    public async Task IsActiveAsync(IsActiveContext context)
    {
        // Optional: Check if the user is active in your system
        context.IsActive = await _authService.IsUserActiveAsync(context.Subject.GetSubjectId());
    }
}

With this setup, IdentityServer acts only as a claims transmitter, not a storage system—all permission data lives in your own services.

4. Use Token Introspection for real-time authorization checks #

If permissions can change frequently and you need real-time validation, use IdentityServer’s Token Introspection endpoint:

• The resource server sends the Bearer Token to IdentityServer’s introspection endpoint.
• IdentityServer validates the Token, then can call your authorization service to fetch the user’s current permissions before returning details to the resource server.
• The resource server uses this real-time data to decide whether to allow the request.

Note: Token introspection adds a small latency overhead, so it’s best suited for scenarios where permissions change often or token lifetimes are long.

内容的提问来源于stack exchange，提问作者Jepthy