Problem with Entra-ID (aka AzureAD) and using groups to protect a URL

[mshaddock]

I'm trying to protect a URL with a group in Entra-ID (aka AzureAD).

The config:

# Azure AD auth using auth_openidc_module
# Hack/workaround to allow mod_auth_openidc to use non-openidc spec compliant UserInfo endpoints
SetEnvIfExpr true OIDC_NO_USERINFO_SUB = true

OIDCProviderMetadataURL "https://login.microsoftonline.com/some-uuid-here/v2.0/.well-known/openid-configuration"
OIDCClientID "other-uuid-here"
OIDCClientSecret "super secret string here"

# OIDCRedirectURI is a vanity URL that must point to a path protected by this module but must NOT point to any content
OIDCRedirectURI /secure/redirect_uri
OIDCCryptoPassphrase "different super secret string"

OIDCProviderJwksUri https://login.microsoftonline.com/yet-another-uuid/discovery/v2.0/keys

OIDCProviderUserInfoEndpoint "https://graph.microsoft.com/v1.0/me?$select=mailNickname,onPremisesSamAccountName"

OIDCXForwardedHeaders X-Forwarded-Port X-Forwarded-Proto

OIDCSessionInactivityTimeout 3600

# Custom cookie settings
OIDCCookie "openidc_session"
OIDCSessionType client-cookie
OIDCCookieSameSite On
OIDCStateMaxNumberOfCookies 15 true

OIDCScope "openid email"
OIDCRemoteUserClaim onPremisesSamAccountName

mod_auth_openidc version 2.4.11
Apache 2.4.58

Users are defined in Entra-ID as

dn: CN=[XXX] Special Foo Users,OU=Groups,OU=US,OU=Servers,DC=na,DC=example,DC=com
sAMAccountName: foousers

I've added a groups claim with all groups (also tried just Security Groups) with these permutations:

ID, Access, and SAML are set to "Group ID"
ID, Access, and SAML are set to "Group ID"  and "Emit groups as role role claims"
ID, Access, and SAML are set to "sAMAccountName"
ID, Access, and SAML are set to "sAMAccountName"  and "Emit groups as role role claims"

I'm trying to protect a URL with

<Location /foo>
    AuthType openid-connect
    
    # These are commented out,  but are the permutations that I've tried.
    # Require claim "dynamic_group:[XXX] Special Foo Users"
    # Require claim "dynamic_group:foousers"
    # Require claim "group:[XXX] Special Foo Users"
    # Require claim "group:foousers"
    # Require claim "realm_access.roles:[XXX] Special Foo Users"
    # Require claim "realm_access.roles:foousers"
    # Require claim "memberOf:[XXX] Special Foo Users"
    # Require claim "memberOf:foousers"

</Location>

At this point I am out of ideas to try. Any suggestions?

[mshaddock]

After updating my App Registration Authentication to use ID tokens, I now get an id_token back that looks like this (with some bits stripped out):

{
   "iss" : "https://login.microsoftonline.com/{TENANT ID}/v2.0",
   "_claim_sources" : {
      "src1" : {
         "endpoint" : "https://graph.windows.net/{TENANT ID}/users/00000000-0000-0000-0000-000000000000/getMemberObjects"
      }
   },
   "aud" : "{CLIENT ID}",
   
   "_claim_names" : {
      "groups" : "src1"
   },

   "ver" : "2.0",
   "roles" : [
      "User.Read"
   ],
}

From my reading, when "groups" is set to "src1", it indicates that the token won't get so large as to exceed HTTP header limits (see https://learn.microsoft.com/en-us/entra/identity-platform/id-token-claims-reference#groups-overage-claim). In our organization this isn't surprising. So _claim_sources.src1.endpoint is the URL of where to check the group membership, but I don't see how to do that with a nested claim.

[mshaddock]

It turns out that the fix for this was to use LDAP as described in https://github.com/OpenIDC/mod_auth_openidc/wiki/Authorization.