Add Support for Azure AD appRoles Claims in OIDC Authentication

[amitej25]

Is your feature request related to a problem? Please describe.
Feast currently supports OIDC-based authentication and expects the resource_access claim in the access token to manage roles and permissions. However, Azure AD issues tokens with appRoles instead of resource_access, causing a mismatch between the token structure and Feast's expectations.

This leads to challenges when integrating Feast with Azure AD for authentication, as Feast cannot interpret the appRoles claim.

Describe the solution you'd like
Enhance Feast's OIDC implementation to support multiple token formats by:

Checking for the appRoles claim when resource_access is not found.

Additional context
Observed Behavior:
When using Azure AD for OIDC-based authentication, the access token contains the following structure:

{
  "appRoles": [
    {
      "allowedMemberTypes": ["User", "Application"],
      "displayName": "feast.reader",
      "value": "feast.reader"
    },
    {
      "allowedMemberTypes": ["User", "Application"],
      "displayName": "feast.writer",
      "value": "feast.writer"
    }
  ]
},

Feast, however, expects the token to contain the resource_access claim:

{
  "resource_access": {
    "app": {
      "roles": ["reader", "writer"]
    }
  }
}

This results in Feast failing to validate roles and permissions from the Azure AD token.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[larrysingleton007]

For anyone still watching this: the top-level roles claim gap raised here is fixed in #6631 (along with the app-only username gap that also blocked Entra ID), which supersedes this issue.