1. Proposed title of this feature request

Support for Microsoft Entra ID (Azure AD) Group Overage Claims

2. What is the nature and description of the request?

Currently, OpenShift GitOps (Argo CD) cannot authorize users when their group memberships exceed the limit handled by the ID Token (the "overage" scenario). While the OIDC specification defines a method for distributed claims, Microsoft Entra ID utilizes a proprietary "overage" claim that requires a specific call to the Microsoft Graph API to resolve group memberships.

When a user belongs to more than 200 groups (JWT) or 150 groups (SAML), Entra ID emits a claim: "_claim_names": {"groups": "src1"}. To resolve these, the client must use the provided Access Token to query the Microsoft Graph getMemberObjects or transitiveMemberOf endpoints.

Because Argo CD’s current OIDC implementation only looks for the groups claim within the initial token or the standard userinfo endpoint, these enterprise users are effectively always without groups from ArgoCD's perspective.

Requested Capability:

• Implement a specific handler for Entra ID overage claims (_claim_names / _claim_sources).
• Enable Argo CD to use the user's Access Token to query the Microsoft Graph API to fetch group IDs when an overage is detected.
• Support mapping these Graph-resolved Group IDs to Argo CD RBAC roles.

3. Why does the customer need this? (List the business requirements here)

The inability to handle non-compliant Azure overage claims is a critical blocker for our enterprise identity strategy:

Security Risk: To circumvent this issue, we are forced to use "manual" local user management or overly broad group assignments, which violates our "Zero Trust" and "Least Privilege" security policies.
Enterprise Scale: Our organization’s Active Directory is deeply nested. Most of our senior engineers and architects—the primary users of Argo CD—trigger the overage claim. This prevents our most critical staff from using the platform effectively.
Operational Cost: We are currently forced to build and maintain "token-trimming" proxies or custom sidecars to flatten groups before they reach Argo CD. This adds significant architectural complexity and a point of failure to our GitOps pipeline.

4. List any affected packages or components.