azuread_application: unexpectedly has an 'exposed API' when viewed in the preview portal

[DavidR91]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform 0.11.13 / Azure AD 0.2.0

Affected Resource(s)

• azuread_application

Terraform Configuration Files

resource "azuread_application" "app" {
	name = "Example"
	homepage = "https://example"
	reply_urls = "https://example"
	oauth2_allow_implicit_flow = true

	// Microsoft Graph 
	// (not in order):
	// - Directory.Read.All
	// - Group.Read.All
	// - User.Read
	// - User.ReadBasic.All
	// - User.ReadWrite
	required_resource_access {
		resource_app_id = "00000003-0000-0000-c000-000000000000"
		
		resource_access {
			id = "06da0dbc-49e2-44d2-8312-53f166ab848a",
			type = "Scope"
		},

		resource_access {
			id = "5f8c59db-677d-491f-a6b8-5f174b11ec1d",
			type = "Scope"
		},

		resource_access {
			id = "e1fe6dd8-ba31-4d61-89e7-88639da4683d",
			type = "Scope"
		},

		resource_access {
			id = "b340eb25-3456-403f-be2f-af7a0d370277",
			type = "Scope"
		},

		resource_access {
			id = "b4e74841-8e56-480b-be8b-910348b18b4c",
			type = "Scope"
		}
	}

	// Azure management API
	//(not in order):
	// - user_impersonation
	required_resource_access {
		resource_app_id = "797f4846-ba00-4fd7-ba43-dac1f8f63013"
		
		resource_access {
			id = "41094075-9dad-400e-a0bd-54e686782033",
			type = "Scope"
		},
	}
}

Expected Behavior

The Azure AD application created should have the specified API permissions when viewed in the preview portal

Actual Behavior

Although the application has the permissions specified, it also gains an 'exposed API' visible in the preview portal:

The exposed API correlates with the 41094075-9dad-400e-a0bd-54e686782033 permission (user_impersonation).

The behaviour is definitely odd because an application ID is not set, so the portal displays an undefined prefix:

Important Factoids

I'm reasonably certain this is a bug: adding these scopes shouldn't cause APIs to be exposed, and the scope is usable without the API exposed

Exposed APIs seem to be decided by this block of the manifest, which does not correlate with the attributes set in the HCL:

"oauth2Permissions": [
	{
		"adminConsentDescription": "Allow the application to access Scope test 2 on behalf of the signed-in user.",
		"adminConsentDisplayName": "Access Scope test 2",
		"id": "07b4045a-51de-4e05-bc63-cf4f10c931b6",
		"isEnabled": true,
		"lang": null,
		"origin": "Application",
		"type": "User",
		"userConsentDescription": "Allow the application to access Scope test 2 on your behalf.",
		"userConsentDisplayName": "Access Scope test 2",
		"value": "user_impersonation"
	}
],

The big issue is tracking down where this issue is introduced, i.e. is it

• The provider
• A breaking change or bug in the Azure API
• Some kind of bug in the preview portal that causes it to add this information?

Note

I can provide a debug log but it seems to be of limited use since it does not contain HTTP request bodies or their responses

[tiwood]

I'm pretty sure the user_impersonation scope is added by default. You are right that this is not displayed in the legacy view, but it should be there nevertheless.

UPDATE
I've just created an application through the Portal and the user_impersonation scope was added by default. This may be the case because you enable oauth2_allow_implicit_flow.

[katbyte]

Hi @DavidR91, have you tried creating an application without oauth2_allow_implicit_flow set to true?

(also thanks again for the answer @tiwood!)

[lzadjsf]

Hi @katbyte,
I faced the same issue.
azuread plugin has version v0.5.1_x4.
Also I did try both true and false conditions for oauth2_allow_implicit_flow - no difference, the same behaviour in both run.

[joakimhellum]

Hello, sorry for my ignorance, but why is this a issue?

This has been the default for as long as I can remember:

Where does the default oauth2Permissions entry come from?

Answering this question requires a bit of history. For the way in which Azure AD is organized, a token obtained by a client for accessing a web API must contain at least a scope—which is, as you have seen, an action that the client obtains permissions to perform. An application representing a web API but not defining any scopes would be impossible to access because any token request would not have any scope to prompt consent for. That wasn’t always the case! This constraint was added a few months after Azure AD was released, creating a lot of confusion for developers who were now expected to manually add at least one oauth2Permission entry before being able to use their API. This also influenced all the walk-through and sample readme files at the time, making it necessary to add instructions on how to add that entry. I am happy to report that such manual steps are no longer necessary. Every Application is created with one default permission, user_impersonation, so that if you want to implement your app as a web API you don’t need any extra configuration step, and you can begin development right away. I am telling you all this because some of the walk-throughs from that phase are still around. Now you know that you don’t need to follow them to the letter on this.

Reference:
https://www.microsoftpressstore.com/articles/article.aspx?p=2473127

[joakimhellum]

Hi again, sorry for missing this:

The behaviour is definitely odd because an application ID is not set, so the portal displays an undefined prefix

The application ID in this context is also referred to as identifier_uris. This could be fixed by setting the identifier_uris for the application. I think Azure CLI normally sets the identifier_uris by default, but currently azuread_application resource in Terraform AzureAD provider don't do it.

However I believe these are two different issues:

• default OAuth2 permissions
• no default identifier_uris

[manicminer]

Thanks for raising this! As mentioned, the user_impersonation scope is added by default to new application registrations.

You will be able to override this with #252 by setting:

resource "azuread_application" "example" {
	name = "Example"
	homepage = "https://example"
	reply_urls = "https://example"
	oauth2_permissions = []
}

[ghost]

This has been released in version 0.10.0 of the provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading. As an example:

provider "azuread" {
    version = "~> 0.10.0"
}
# ... other configuration ...

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 hashibot-feedback@hashicorp.com. Thanks!