IdentityServer4.AddScopes creates invalid connect requesturl - asp.net-core

Question

We have successfully implemented IdentityServer4 which is working well for the two simple websites. The current project however, has a very complex set of policies, each with multiple requirements. And therefore we have many [Authorize(policy: policyname)] attributes on various controller actions.
The issue I am facing is I have added each of these policies as scopes to reduce the returned claims, but now the initial connect request fails with HTTP Error 404.15 - Not Found because the request url is too long.
e.g. reduced length for simplicity: https://localhost:44364/connect/authorize?client_id=Jbssa.HRX.Web&redirect_uri=https%3A%2F%2Flocalhost%3A44352%2Fsignin-oidc&response_type=code%20id_token&scope=openid%20profile%20offline_access%20Jbssa.HRX.BulkEventDocumentAttachs%20Jbssa.HRX.BulkEventDocumentDeletes%20Jbssa.HRX.BulkEvents%20Jbssa.HRX.Categories%20Jbssa.HRX.CheckerboardOutputEmployeeHistory....M&x-client-SKU=ID_NETSTANDARD2_0&x-client-ver=5.3.0.0
Now I could reduce the length of the claim type names but this would only be a stop gap.
This is an ASP.NET Core 2.2 website and I setup OpenIdConnect as follows within ConfigureServices:
services.AddOpenIdConnect(KnownAuthenticationScheme.JbsMainOidc, options =>
{
options.SignInScheme = KnownAuthenticationScheme.JbsMainCookie;
options.Authority = settings.Authority;
options.ResponseType = settings.ResponseType;
options.ClientId = settings.ClientId;
options.ClientSecret = settings.ClientSecret;
options.RequireHttpsMetadata = settings.RequireHttpsMetadata;
options.SaveTokens = true;
options.GetClaimsFromUserInfoEndpoint = true;
options.ClaimActions.MapAll();
// add all scopes possible for the website
AddScopes(options.Scope);
options.TokenValidationParameters = new TokenValidationParameters
{
NameClaimType = JwtClaimTypes.Name,
RoleClaimType = JwtClaimTypes.Role
};
})
and the AddScopes call looks like this:
static partial void AddScopes(ICollection<string> scopes)
{
scopes.Add(IdentityServerConstants.StandardScopes.OpenId);
scopes.Add(IdentityServerConstants.StandardScopes.Profile);
scopes.Add("offline_access");
foreach (var item in SupportedPolicies.GetList())
scopes.Add(item);
}
Because I don't have access to the Request URL during configuration I can't reduce the number of scopes to just the policies defined for the calling action.
For example:
[Authorize(SupportedPolicies.Categories)]
public partial class CategoriesController : Core.Mvc.ControllerBase
should only be using the "Categories" policy requirements therefore the request to IdSrv4 should be something like, should it not?
https://localhost:44364/connect/authorize?client_id=Jbssa.HRX.Web&redirect_uri=https%3A%2F%2Flocalhost%3A44352%2Fsignin-oidc&response_type=code%20id_token&scope=openid%20profile%20offline_access%20Jbssa.HRX.Categories&x-client-SKU=ID_NETSTANDARD2_0&x-client-ver=5.3.0.0
Or am I missing/not understanding something?
Update 16 aug
I think I understand what you are saying Ruard, and I understand the concept of authentication vs authorization. We have our own "PolicyServer" and it defines the roles/permissions for our applications. The issue I am having is with IdentityServer 4, when it makes it's initial connect request (read, not our code) it combines all the AllowedScopes into that connect request to determine the claims to return. These claims can be against multiple things, Identity or Api Resources, even the Client and Roles can have attached claims. But all these are filtered by the scope of the request. We have over 60 possible scopes that secures various resources and these I thought needed to be defined when we register OpenId via the AddScopes method (seen above).
To be more specific, when we don't include all the scopes, this SQL is being generated by IdentityServer4 within the connect request:
SELECT [api].[Id], [api].[Description], [api].[DisplayName], [api].[Enabled], [api].[Name]
FROM [dbo].[ApiResource] AS [api]
WHERE EXISTS (
SELECT 1
FROM [dbo].[ApiScope] AS [x]
WHERE [x].[Name] IN (N'openid', N'profile', N'Jbssa.HRX') AND ([api].[Id] = [x].[ApiResourceId]))
ORDER BY [api].[Id]
And this determines the resources to check for claims. If the scope does not exist, no resource is located and the STS returns an 'Invalid Scope' error. Hence why I added all the scopes and it now returns the Url Too long error.

Answer 1

We changed the way our clients requested the scopes and instead reduced the number of scopes to just a few and application the appropriate claims to these. It increased the access token size and therefore the response time, but it was not significant enough to warrant looking for other solutions.