Why Are 'Other Permissions' Automatically Added in a Terraform Enterprise App and How Can I Add Extra Graph API Scopes?

Below is an explanation addressing your two main questions.

---

1. Why is the RED “Other Permissions” Section Added and Can It Be Removed?

When you include the OpenID Connect (OIDC) permission (i.e. “openid”) in your required resource access, Azure Active Directory automatically adds the standard default OIDC scopes (like profile, email, offline_access) to your application’s manifest. This is built into the OIDC specification. The “Other Permissions” section you see in the portal reflects these automatically‐added scopes.

Key point:
These automatically added permissions are inherent to how OIDC is implemented. In other words, if you want to use OIDC (and have “openid” included), you cannot remove these additional scopes as they are required by the protocol. If you really didn’t want them, you’d have to stop using OIDC. However, typically these scopes are needed (or at least harmless) for most applications.

---

2. How Do I Add Other Permissions Like email, profile, offline_access?

If you wish to explicitly add or modify permissions such as email, profile, or offline_access, you have two main options:

1. Explicitly Define Them in Your Required Resource Access Block:
   If the API (for example, Microsoft Graph) exposes these scopes as part of its oauth2PermissionScopes, you can reference them just as you did with “openid” or “User.Read”. For example:

   HCLCopied
   resource "azuread_application" "enterprise_app_oidc" {
     display_name = var.ent_app_display_name
     owners       = distinct(var.ad_group_owners)
   
     required_resource_access {
       resource_app_id = data.azuread_application_published_app_ids.well_known.result.MicrosoftGraph
   
       resource_access {
         id   = azuread_service_principal.msgraph.oauth2_permission_scope_ids["openid"]
         type = "Scope"
       }
   
       resource_access {
         id   = azuread_service_principal.msgraph.oauth2_permission_scope_ids["User.Read"]
         type = "Scope"
       }
   
       // If available, you can define additional scopes explicitly:
       resource_access {
         id   = azuread_service_principal.msgraph.oauth2_permission_scope_ids["email"]
         type = "Scope"
       }
   
       resource_access {
         id   = azuread_service_principal.msgraph.oauth2_permission_scope_ids["offline_access"]
         type = "Scope"
       }
       
       // ... add others as needed and supported
     }
   }

   Note: Not every scope (e.g., “profile”) might be exposed as a configurable scope from Microsoft Graph. Some are enforced automatically by Azure AD when using OIDC. You can only reference those permission scopes that the Graph (or any other resource API) actually provides in its oauth2PermissionScopes collection.

2. Application Manifest or Additional Terraform Attributes:
   For some permissions, if they’re not directly configurable via the required resource access block, you might need to adjust the application manifest itself. However, for Graph API and OIDC flows, the default behavior is that some scopes are automatically inserted by Azure AD.

---

Why Create a Second Service Principal (msgraph)?

The Terraform documentation recommends creating (or referencing) the Microsoft Graph service principal because it holds metadata like its oauth2PermissionScope IDs. In your configuration, creating the azuread_service_principal.msgraph resource (with use_existing = true) lets you reference those IDs (for openid, User.Read, email, etc.) dynamically. It’s simply a way to ensure you reference the correct IDs as they can vary between tenants or over time.

---

In Summary

• Other Permissions: The “other permissions” section is automatically added because OIDC requires default scopes (profile, email, offline_access) along with openid. There isn’t an option to remove these if you intend to use OIDC.
• Adding More Permissions: To include additional permissions (beyond what is automatically inserted), add extra resource_access blocks in your required resource access configuration as long as those scopes are exposed by the API (like Microsoft Graph). If a permission (e.g. “profile”) is part of the default OIDC set, it cannot be added “manually” in the same way.

I hope this clears up the confusion! Let me know if you need further help with your Terraform configuration.