AccessToken must not be longer than 4K

Question

I have used Azure SignalR service. It works fine for test project but when i embed in my real project. It throw error (Access Token must not be longer than 4K).

Access Token must not be longer than 4K. 413 Request Entity Too Large

We were using SignalR in our project, now we are shifting to Azure SignalR Service. I have made a Test Project where i used Azure SignalR Service, It was working fine there but i embed that in my real project it throws error (Access Token must not be longer than 4K). I have tried different solution on IIS and in web.config level, increase size of messages kind of things but nothing works. I have check my cookie size its less than 1k. Couldn't get the working of Azure SignalR Service connection making. Why it works in test project. Mean is it include cookies and claims from page that exist on my page in case of real project.

I got this thing but it doesn't work in Asp.net because its core example.

services.AddSignalR()
        .AddAzureSignalR(options =>
            {
                options.ClaimsProvider = context => context.User.Claims;
            });

I have tried bindings in web.config but increase size of message doesn't work because its header level thing.

<bindings>
      <basicHttpBinding>
        <binding name="basicHttpBinding" maxReceivedMessageSize="524288000"/>
        <binding name="mexHttpBinding" maxReceivedMessageSize="524288000" />
      </basicHttpBinding>
</bindings>

Nauman Asghar · Answer 1 · 2020-08-26T11:33:59.993

4

I got the reason. Its claims issue. I have a lot of Claims on my real project because of their size my request exceed the 4k limit. I have used compression and things are working fine for me. Thanks

edited Aug 26 '20 at 11:33

answered Jun 26 '19 at 15:51

Nauman Asghar

111
10

I'm getting the same error even though my token is smaller than 4k – Mando Aug 26 '20 at 00:43
Have you passed claims in MapAzureSignalR, if yes then please pass it as null and check if issue still persist. If issue is solved then definitely its claims size issue. – Nauman Asghar Aug 26 '20 at 11:32

score 3 · Accepted Answer · edited Jun 27 '19 at 09:12

3

For ASP.NET you can use the following to simply pass through a empty claim if your Hub does not have advanced authentication such as role based authentication.

app.MapAzureSignalR(GetType().FullName
                    , options => options.ClaimsProvider = context => new Claim[] {});

edited Jun 27 '19 at 09:12

Piotr Kamoda

956
1
9
24

answered Jun 27 '19 at 06:57

Uzair Ahmed Khan

46
2

If you do not need Claims in SignalR Hub then definitely you go for this solution to pass empty Claims in Azure SignalR map. – Nauman Asghar Jun 28 '19 at 19:55
I do not need Claims in SignalR Hub so i am going with the solution. Thanks for answering. Have a great day! – Nauman Asghar Jun 28 '19 at 19:57
2

@Uazir, What if i do need authentication? how can we solve the issue of the issue ? – Avi Siboni Jul 13 '20 at 07:30

Daniël J.M. Hoffman · Answer 3 · 2022-02-14T15:11:18.493

After adding Role Claims to my app (Blazor Server .NET 6, with Azure SignalR) - I ran into this issue.

If your app does make use of Policy/Claim based authorization, AFAIK you have two options to fix this:

Option 1: Ensure that you are only loading the claims that you need, and that you only include each claim once. In my project, I made use of RoleClaims. When two roles had the same claims, and a user had both roles assigned, the claims were added to the access token again. In my project, the issue was resolved when I simply filtered all claims to include only distinct claims (by Value):

My Example: In Startup.cs

services.AddSignalR()
        .AddAzureSignalR(options =>
            {
                // include only necessary claims
                  options.ClaimsProvider = context => context.User.Claims.ToList().DistinctBy(d => d.Value);
            });

Option 2:

If your Access Token is still too long after filtering (option 1) - instead you can load and check the claims with each request (however - in my experience this was slower than option 1) as explained in this answer.

AccessToken must not be longer than 4K

3 Answers3