Application Registration Configuration

The Configuration tab gives application administrators a guided workspace for changing the Microsoft Entra application registration without switching to the Entra portal. It covers redirect platforms, supported accounts, authentication behavior, app roles, exposed API scopes, and trusted pre-authorized clients.

This workspace changes the application registration itself. It does not grant Microsoft Graph permissions, approve API permission requests, create consent grants, or bypass the normal permission request and administrator-consent process.

Availability and Access

A tenant administrator controls whether registration configuration is available. Open Tenant Administration → Application Settings → General, enable Registration Configuration, and save the tenant settings. The Configuration tab is then available on managed application detail pages in both the WebUI and WA experiences.

• The application must already be managed by AZExecute and must still resolve to an Entra application registration.

• Tenant administrators and application administrators can save changes when they have management access to the application.

• Users who may view an application without managing it see the same configuration in read-only mode with an explanation that saving is restricted.

• AZExecute must have sufficient Microsoft Graph application-management permissions and ownership of the Entra application registration.

Enabling the feature gives authorized application administrators a direct way to update registration properties. Review ownership and administrator assignments before enabling it tenant-wide.

How the Workspace Is Organized

Open an application, select Configuration, and use the vertical navigation to move between five focused areas. Summary chips show the supported-account model and the current number of redirect URIs, app roles, and exposed scopes.

1. Redirect URIs — configure return addresses separately for Web, single-page, and public-client platforms.

2. Supported accounts — choose which Microsoft identity audiences can use the application.

3. Authentication settings — configure home and logout URLs, public-client behavior, and legacy browser token flows.

4. App roles — define role claims for users, groups, applications, or both.

5. Expose an API — configure identifier URIs, access-token version, delegated scopes, and pre-authorized clients.

Redirect URI Configuration

Redirect URIs are grouped by Microsoft identity platform type because the platform controls authentication and token behavior, not just how the address is displayed. Register each callback under the platform that actually performs the sign-in flow.

Web

Use Web for confidential, server-hosted applications such as ASP.NET Core, Java, or Node applications that can safely keep a client secret or certificate. Web redirects accept HTTPS. HTTP is accepted only for loopback/local development addresses.

Single-page application

Use this platform when authentication runs in browser code, including JavaScript and WebAssembly clients using authorization code with PKCE. Do not place a server callback here simply because it shares the same public hostname.

Mobile and desktop applications

Use this platform for native desktop, mobile, CLI, device, or other public clients that cannot safely store a secret. Loopback addresses and custom URI schemes are supported. The shortcut Add Microsoft native client redirect adds https://login.microsoftonline.com/common/oauth2/nativeclient when it is not already present.

Redirects must be absolute URIs and cannot contain a fragment. Duplicate entries are removed during normalization. For Web and SPA platforms, non-loopback HTTP addresses are rejected; use HTTPS outside local development.

Supported Account Types

Supported accounts control the application registration's sign-in audience. Changing this setting can affect issuer validation, tenant onboarding, token endpoints, and which identities your application must handle.

• Accounts in this organization only: single-tenant use for identities and workloads in the current Entra tenant.

• Accounts in any Microsoft Entra organization: multitenant organizational accounts; each consuming tenant must establish the required service principal and consent.

• Accounts in any organization and personal Microsoft accounts: accepts organizational and consumer Microsoft identities.

• Personal Microsoft accounts only: excludes organizational work and school accounts.

Applications supporting personal Microsoft accounts must expose version 2 access tokens. The workspace automatically selects version 2 and prevents version 1 for those audiences.

Authentication Settings

Web application URLs

• Home page URL is the optional application landing page. It must be an absolute HTTP or HTTPS URL.

• Front-channel logout URL receives a sign-out notification from Microsoft Entra. It must also be an absolute HTTP or HTTPS URL.

Public client flows

Allow public client flows marks the registration as a fallback public client. Enable it only when an installed application cannot securely retain a secret. A normal server application should remain a confidential client.

Implicit grant and hybrid flows

Access-token and ID-token issuance switches support applications that explicitly depend on legacy implicit or hybrid flows. New browser applications should use authorization code with PKCE. Enabling these switches is not required simply because the application has an SPA redirect URI.

App Roles

App roles define authorization values emitted in the roles claim. They can represent permissions for a signed-in user or group, application-only permissions for a workload, or a role that supports both scenarios.

• Display name is the administrator-facing role name.

• Token value is the stable value application code checks, for example Orders.Read.

• Description explains the access granted and is required by Entra.

• Users and groups allows assignment to interactive identities. Applications allows app-only assignment. At least one member type is required.

• Role enabled controls whether the role is available for new use.

New roles receive a stable identifier automatically. Display names, descriptions, and token values are required, and token values must be unique. An existing enabled role must be disabled and saved before it can be removed; a newly added, unsaved role can be removed immediately.

Expose an API

Application ID URIs

The identifier URI is the API's logical identifier, scope prefix, and token audience. Most APIs need one value such as api://<client-id>. Microsoft Graph supports a collection of identifier URIs for advanced compatibility scenarios even though the Entra portal normally presents a single editor. Values must be absolute, unique, and appropriate for the registration's supported-account model.

Access token version

Choose the tenant default, version 1, or version 2 token format. Prefer the tenant default unless the API validates a specific format. Version 2 is mandatory when personal Microsoft accounts are supported.

Delegated permission scopes

Delegated scopes are permissions requested on behalf of a signed-in user. For application-only authorization, create an app role that allows Applications instead.

• Scope value is the stable value requested by a client, for example access_as_user. Scope values must be unique.

• Who can consent selects administrators only or administrators and users.

• Admin consent display name and description are always required.

• User consent display name and description are optional. Leave them empty when administrator-provided consent text is sufficient.

• Scope enabled controls whether the scope is available for clients.

Existing enabled scopes follow the same safe-removal sequence as app roles: disable and save first, then remove and save again. Removing a scope also removes it from any pending pre-authorized-client selection in the workspace.

Pre-authorized client applications

Pre-authorization allows a trusted client to use selected delegated scopes without another user consent prompt. Add a client, search the autocomplete by application name or client ID, select another AZExecute-managed application, and choose one or more enabled scopes.

• The picker reads managed applications from the tenant database; it does not search every application in Entra.

• The API currently being configured is excluded, and an application already selected in another row is not offered again.

• Every client requires a valid application (client) ID and at least one exposed scope.

• A pre-existing Graph client that is not managed by AZExecute remains visible as an unmanaged application so loading and saving does not silently discard it.

Pre-authorization is a trust decision. Only pre-authorize a client you control and only for the scopes it genuinely requires. This setting does not grant application roles or Microsoft Graph permissions.

Validation, Saving, and Entra Propagation

Changes remain local to the page until Save configuration is selected. Discard reloads the current registration from Microsoft Graph and removes unsaved changes.

1. The client validates required fields, URI formats, duplicate values, member types, scope references, and token-version compatibility.

2. The backend repeats the same validation before writing to Graph. Whitespace is trimmed, blank optional values are normalized, and duplicate URIs are collapsed case-insensitively.

3. If the registration changed in Entra after it was loaded, the save is rejected as a concurrency conflict instead of overwriting the newer configuration. Discard or reload before trying again.

4. During a valid save, the page displays Updating Microsoft Entra while AZExecute writes the change and reads Graph until the updated values are observable.

5. On success, the page replaces its local state with the confirmed Graph result and shows a success notification. Validation, authorization, Graph, or propagation failures are shown through the standard detailed notification.

Microsoft Graph and the Entra portal can be eventually consistent. AZExecute waits briefly for the saved values to become readable, but another Entra view may still take additional time to refresh.