原IS3用户咨询：IdentityServer4中Scope、IdentityResource与ApiResource的区别

Hey there! I totally get the confusion when moving from IdentityServer3 to 4—those changes around scopes and resources threw me for a loop at first too. Let me break down how these pieces fit together now, compared to what you knew before.

Quick Recap of IdentityServer3 Scopes #

Back in IS3, everything related to user identity and API access was lumped under the single "Scope" concept. You’d define a scope for things like openid (to get the user’s unique ID), profile (for name/avatar details), or api1 (to grant access to your backend API). It worked, but it mixed two distinct concerns: who the user is, and what the client can do.

What Changed in IdentityServer4? #

IS4 cleaned this up by splitting the old Scope into two dedicated, purpose-built resource types: IdentityResource and ApiResource. The "scope" term still exists, but it’s now a sub-concept under these two resources. Let’s break each down:

1. IdentityResource #

• Core Purpose: This is all about who the user is—it defines the identity-related claims (like name, email, role) that clients can request. Think of it as replacing the old "identity scopes" from IS3.
• Built-in Options: IS4 comes with pre-configured identity resources for common use cases: openid (required for OpenID Connect compliance), profile, email, phone, and address. You can use these out of the box.
• Custom Example: If you need to expose custom user data (like department info), you’d define it like this:

public static IEnumerable<IdentityResource> GetIdentityResources()
{
    return new List<IdentityResource>
    {
        new IdentityResources.OpenId(),
        new IdentityResources.Profile(),
        // Custom identity resource for department details
        new IdentityResource(
            name: "department",
            displayName: "Department Information",
            claimTypes: new[] { "department_name", "department_id" })
    };
}

• Note: When a client requests these scopes, the corresponding claims are included in the ID token or returned via the UserInfo endpoint.

2. ApiResource #

• Core Purpose: This is for what the client can do—it defines your protected APIs and the granular permissions (scopes) needed to access them. This replaces the old "API scopes" from IS3.
• Granular Permissions: Each ApiResource can have multiple sub-scopes to split access into fine-grained permissions. For example, an e-commerce API might have orders.read, orders.write, and products.read scopes.
• Example Configuration:

public static IEnumerable<ApiResource> GetApiResources()
{
    return new List<ApiResource>
    {
        new ApiResource("ecommerce_api", "Ecommerce Platform API")
        {
            Scopes = { "orders.read", "orders.write", "products.read" },
            // Optional: Include user claims in access tokens for API validation
            UserClaims = { "name", "email" }
        }
    };
}

3. The "Scope" Concept Now in IS4 #

Don’t worry—the word "scope" hasn’t disappeared entirely. It’s just become a child of the two resource types:

• For IdentityResources: Each identity resource is itself a scope (e.g., openid is an identity scope).
• For ApiResources: The sub-items under an ApiResource are the API scopes (e.g., orders.read is an API scope).
  When a client makes a request, it still lists all needed scopes in the scope parameter—like scope=openid profile orders.read.

Key Takeaways to Keep Straight #

• IdentityResource: Answers "Who is this user?" (identity data, tied to OpenID Connect).
• ApiResource: Answers "What can this client access?" (API permissions, tied to OAuth2).
• The split makes configurations more organized and aligns better with the original intent of the OpenID Connect and OAuth2 specifications—no more mixing identity and API access logic in a single scope definition.

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