[Feature request] Support group overage out-of-the-box in JWT group claim

[ABrethome]

First, apologies if this is not within scope of this package. I haven't found information suggesting it is not, and I haven't found closed issues talking about it. :) I have not read anything in the doc suggesting it is already implemented either.

Describe the feature you'd like
groups claim in JWT from Azure has a limit of 200.
https://learn.microsoft.com/en-us/entra/identity/users/directory-service-limits-restrictions

When a signed-in user has a groups claim above the threshold, a group overage is sent back in the JWT with a url to Microsoft Graph.
There are ways to handle this automatically at a first glance.
https://learn.microsoft.com/en-us/troubleshoot/entra/entra-id/app-integration/get-signed-in-users-groups-in-access-token
https://github.com/Azure-Samples/fastapi-appservice-ad-authz/tree/main

I suggest to add group overage handling out-of-the-box from the JWT, so that the User object returns all groups, even if a group overage is sent back.

[JonasKs]

Hi!

This is a valid question, and I've received it many times over the years (especially in Django-auth-ADFS).

I suggest using `roles' and not groups, described here.

I do my best to only add features for the golden path to this library. Anything out of that, I prefer trying to help you implement what you need yourself.

I am on my phone right now(so expect syntax errors), but I suggest something like this:

from fastapi import Depends
from fastapi_azure_auth.exceptions import Unauthorized
from fastapi_azure_auth.user import User

class CustomUser(BaseModel):
    groups: list[str]

async def check_groups(user: User = Depends(azure_scheme)) -> CustomUser:
    # check if we must fetch groups manually 
    # populate our CustomUser 
    # return CustomUser 


@app.get("/items/")
def read_items(user: CustomUser):
    ...

(I'd still use annotated as described in my link above)

[ABrethome]

Thanks @JonasKs for your quick reply!

Unfortunately, roles are unfit for purpose in my use case I think. I have N features, and I want to control access to each feature, where a user must be part of X groups (intersect) to be given a role that gives access to that feature. I don't think it is possible with roles, so I do the verification at the groups level directly. Or am I missing something out in Azure?

In my opinion, group overage would feel more integrated if it was handled within fastapi-azure-auth rather than wrapped around it, but I do get your valid point too 👍

I was planning to implement something similar to your suggestion, but beforehand, I preferred initiating a discussion about a feature request. Now that I got a clear statement, will get going implementing something similar to your suggestion!

Thanks again, issue can be closed.

[JonasKs]

I totally understand, thanks for raising the question. I mostly have this "limitation approach" in order to keep attack surface of this library as small as possible, by having as few configuration options as possible. Every config option and step added requires thorough testing, which becomes hard to maintain after a while. As a solo maintainer, I need to be a bit vary 😊

where a user must be part of X groups (intersect) to be given a role that gives access to that feature

It depends. Nested groups don't work in Azure. How ever, if it's a 1-1 mapping, you can map a group to a role, saying "If user is a direct member of GroupA, add to RoleA. If user is a direct member GroupB, add to RoleB":

I would personally do this, if it's applicable. If it's not, then yeah, your approach is valid.