When user is part of multiple organizations, JWT token size limit reached

[AcidRaZor]

When a user has access to multiple organizations, the claims role & Feature grows outside the bounds of the size limit for a cookie.

Steps to reproduce the behavior:

1. Add a user with multiple roles and Features to multiple organizations until it breaks

Expected behavior:
Unsure to be honest. Although it might not pose a problem for most, there is a scalability issue, especially if you're an administrative person looking after multiple organizations or a user with multiple features stretched across several organizations

Snippet of a large one, but still within it's limits (for now)

"Feature": [
    "Platform_platform_trial_features",
    "Platform_platform_pro_features",
    "Platform_platform_enterprise_features",
    "Platform_platform_basic_features",
    "Tenant_tenant_trial_features#|#org_PpVJEFqv20Krx1HM72SDjw",
    "Tenant_tenant_pro_features#|#org_PpVJEFqv20Krx1HM72SDjw",
    "Tenant_tenant_enterprise_features#|#org_PpVJEFqv20Krx1HM72SDjw",
    "Tenant_Tenant_Basic_features#|#org_PpVJEFqv20Krx1HM72SDjw",
    "Tenant_tenant_trial_features#|#org_yw6lU9RJZ0eYTFizJ6ocMg",
    "Tenant_tenant_pro_features#|#org_yw6lU9RJZ0eYTFizJ6ocMg",
    "Tenant_tenant_enterprise_features#|#org_yw6lU9RJZ0eYTFizJ6ocMg",
    "Tenant_Tenant_Basic_features#|#org_yw6lU9RJZ0eYTFizJ6ocMg",
    "Tenant_tenant_trial_features#|#org_mECoLGB0rU2RUjGHloONlw",
    "Tenant_tenant_pro_features#|#org_mECoLGB0rU2RUjGHloONlw",
    "Tenant_tenant_enterprise_features#|#org_mECoLGB0rU2RUjGHloONlw",
    "Tenant_Tenant_Basic_features#|#org_mECoLGB0rU2RUjGHloONlw"
  ],

[jezzsantos]

Thanks @AcidRaZor

This is a known issue.

This commit (2546187) added checks and throws exception when limit reached. As the token overrun is otherwise ignored by clients! which is quite alarming, because it breaks AuthN entirely!

In terms of what to do about it.
Stuffing claims in JWTs has ALWAYS been a concern for all systems.
Not only do we potentially hit limits (depends on what is stuffed into the token), but when those claims change (for example, when a user is added to another organization) the existing token does not know about it, and we have to force the user to reauthenticate to get the new claim.

Fortunately, in SaaStack we have another option.

There are two places in each ApiHost where these tokens are even considered:

• AspNetClaimsBasedCallerContext reads these claims from the JWT token, and populates the ICallerContext with Roles and Features for every API call.
• The MultiTenancyMiddleware however, actually ignores the claims in the token, and instead issues a call to the IEndUsersService.GetMembershipsPrivateAsync() method to fetch them from persistence, each API call.

Clearly, this extra API call per API call is undesirable, but may be necessary in some system designs.

So, we could choose not to store Roles and Features in the token, and simply change AspNetClaimsBasedCallerContext to use the same call to IEndUsersService.GetMembershipsPrivateAsync() to fetch the Roles and Features.

We just haven't done that work yet, and to figure out what else this change impact.
That's the known workaround at this stage

[jezzsantos]

This problem has been somewhat minimized, (not eliminated) by reducing the length of roles and features in: d44eb73

Outcome, we can now store many more memberships to more organizations.

However, to eliminate this problem altogether, we can remove roles and features from the token altogether and just verify them in middleware instead of carrying them in the token.
To do that, investigate MultiTenancyMiddleware, and perhaps extend or introduce more middleware to verify memberships for all requests