Share via

App Registration Authentication (Preview) - Impact on Managed Identity Integration among function apps

Pesala, Nikitha 20 Reputation points
2025-11-26T11:00:46.2533333+00:00

Question:

We are implementing a Managed Identity for secure service-to-service communication between two Azure Function Apps. Our setup involves:

Function App A (Caller):

• System-Assigned Managed Identity enabled

• Timer-triggered function requesting JWT tokens

Function App B (Callee):

• Azure AD Authentication configured via Authentication blade in function app

• HTTP-triggered function validating JWT tokens

Configuration Process:

  1. Navigate to Authentication blade → Add identity provider → Microsoft
  2. Create new app registration (Single tenant)
  3. Require authentication with HTTP 401 for unauthenticated requests
  4. Use Application ID URI as audience in caller's token requests

User's image

Concern: When we open app registration after the above process The Authentication blade shows (Preview) status in the Azure Portal.

Questions:

  1. Will the preview status of the Authentication blade affect the reliability or functionality of our Managed Identity authentication flow?
  2. Are there any known limitations or potential issues when using preview Authentication features with System-Assigned Managed Identity?
  3. Is this configuration considered production-ready, or should we implement an alternative approach for production workloads?

Current Flow: Caller uses DefaultAzureCredential → Requests token with Application ID URI scope → Includes JWT as Bearer token → Callee validates via Azure AD authentication.

Please advise if the preview status impacts this implementation or if there are recommended best practices for production environments.

Reference link: Managed identity for Authentication among Azure Function App / App Services

Azure Functions
Azure Functions

An Azure service that provides an event-driven serverless compute platform.

Answer accepted by question author

Rakesh Mishra 9,340 Reputation points Microsoft External Staff Moderator
2025-11-26T11:51:04.1366667+00:00

Hi @Pesala, Nikitha ,

Welcome to the Microsoft Q&A Platform! Thank you for asking your question here.

1. Will the preview Authentication blade affect the reliability or functionality of our Managed Identity authentication flow?
  • No, the managed identity runtime (system-assigned/user-assigned), its service principal/token behavior and access model are platform features and are not changed by a portal UI being in preview.
  • Portal/Blade changes affect management UX only; the runtime token issuance and SDK behavior (for example when your app calls IMDS / DefaultAzureCredential) remain the same.
2. Any known limitations or potential issues when using preview Authentication features with system-assigned managed identity?
  • There are no inherent functional limits to the managed identity itself just because an authentication blade is preview — but preview features can have limited capabilities, regional rollouts, and may change before GA. Treat preview UI features as unstable for automation.
  • Practical risks: documentation may lag, support may be best-effort for preview features, and UI workflows can change — so scripts/runbooks that depend on a preview UI could break.
  • Verification steps you should run (non-prod) to be safe: ensure the MI service principal exists, request a token from the MI endpoint (IMDS/SDK), and validate RBAC access — these validate the auth flow independently of the portal UI.
3. Production readiness — is this configuration production-ready, or should we use an alternative for production workloads?

Short answer: Use the managed identity feature in production, but don’t rely on preview UI features as your only path for production configuration or automation.

  • Use managed identities in production, the capability itself is GA and intended for production use (recommended pattern to avoid secrets).
  • Don’t rely exclusively on a Preview portal workflow for production automation or critical runbooks. For production, provision/configure/automate via GA-supported methods (ARM templates, CLI, PowerShell, REST) or the GA portal blades.
  1. Provision and assign the system-assigned managed identity (ARM/CLI/Portal GA blade).
  2. Grant RBAC to the MI (Storage, Key Vault, etc.) and verify access with a token request from the app.
  3. Use SDKs that support managed identity token acquisition (Azure.Identity / DefaultAzureCredential) and add runtime tests in staging.
  4. Avoid building automation that depends only on a preview portal workflow — use supported APIs/ARM/CLI for automation.

Was this answer helpful?

0 additional answers

Sort by: Most helpful
Most helpful Newest Oldest

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.