Azure can't find microsoft-identity-association.json

Hello Enrico Rossini,

Welcome to the Microsoft Q&A and thank you for posting your questions here.

I understand that your Azure can't find microsoft-identity-association.json.

With your kind of explanation, image and scenario provided, I will classify this into two scenarios where this can happen instead of secondary issues:

Scenario 1: If the domain is verified in a different Microsoft Entra tenant than the app registration.

The reason it fail is because Microsoft Entra doesn’t allow a root domain to be verified in more than one tenant at a time. If contoso.com is already verified elsewhere, it cannot be re-verified in the current tenant. - https://learn.microsoft.com/en-us/entra/identity/users/domains-manage

What you can do are the followings:

1. Recreate the app registration in the tenant that already owns the verified domain
   • In Microsoft Entra admin center, switch to the tenant where the domain is verified (Directories + subscriptions). - https://learn.microsoft.com/en-us/entra/identity-platform/howto-configure-publisher-domain
   • Create a new App Registration in that tenant and reapply the settings (redirect URIs, API permissions, certificates/secrets).
   • Update your application configuration to use the new Application (client) ID.
2. Verify a separate subdomain in the current tenant, then use it as the publisher domain Microsoft explicitly supports verifying a subdomain in a different tenant, even when the root domain is verified in another tenant (for example, europe.contoso.com). - https://learn.microsoft.com/en-us/entra/identity/users/domains-manage
   • Go to Entra ID → Domain names → Add custom domain and add a subdomain (e.g., id.contoso.com). - https://learn.microsoft.com/en-us/entra/identity/users/domains-manage
   • Create the requested DNS TXT record with your DNS provider and complete verification. - https://learn.microsoft.com/en-us/entra/identity/users/domains-manage
   • Then set it on the app: App registrations > (your app) > Branding > Publisher domain > Update domain > Select a verified domain and choose the verified subdomain. - https://learn.microsoft.com/en-us/entra/identity-platform/howto-configure-publisher-domain

NOTE: The /.well-known/microsoft-identity-association.json file is a domain verification method inside the current tenant’s app registration flow, not a way to “reuse” a domain verified in another tenant. - https://learn.microsoft.com/en-us/entra/identity-platform/howto-configure-publisher-domain, https://learn.microsoft.com/en-us/entra/identity/users/domains-manage

Scenario 2: The domain is in the same tenant, but publisher domain verification still fails.

You’re already in the correct tenant, but the verification check can fail if the JSON file isn’t exactly what Entra expects, or if the endpoint response metadata isn’t acceptable.

Perform Step-by-step validation checklist in order:

1. Confirm the tenant actually has the domain verified by
   • Go to Entra ID > Domain names and confirm the domain shows Verified. - https://learn.microsoft.com/en-us/entra/identity/users/domains-manage
   • If the domain is verified, you can usually skip web-host verification and simply select the verified domain from the dropdown. - https://learn.microsoft.com/en-us/entra/identity-platform/howto-configure-publisher-domain
2. If you must “Verify a new domain for your app”, use the exact JSON structure Create a file named: microsoft-identity-association.json as in https://learn.microsoft.com/en-us/entra/identity-platform/howto-configure-publisher-domain Use this validated JSON (replace placeholders with real client IDs):

      {
        "associatedApplications": [
          { "applicationId": "<YOUR_APPLICATION_CLIENT_ID>" }
        ]
      }
   

   Tip: If you’re validating the same domain for multiple apps, include multiple applicationId objects in the array. https://learn.microsoft.com/en-us/entra/identity-platform/howto-configure-publisher-domain

3. Host the file at the required “well-known” path (HTTPS)
   • Publish it exactly here: https://<your-domain>/.well-known/microsoft-identity-association.json https://learn.microsoft.com/en-us/entra/identity-platform/howto-configure-publisher-domain
   • This uses the industry-standard /.well-known/ convention (RFC 8615). https://www.rfc-editor.org/rfc/rfc8615
4. Ensure the response Content-Type is supported:
   • Microsoft Entra expects JSON deserialization and explicitly lists supported response headers such as:
   • application/json
   • application/json; charset=utf-8 - https://learn.microsoft.com/en-us/entra/identity-platform/howto-configure-publisher-domain
   The quick test commands you can use is: curl -i https://<your-domain>/.well-known/microsoft-identity-association.json You should see HTTP 200 and a supported Content-Type.
5. Retry verification from the portal
   • App registrations > (your app) > Branding > Publisher domain > Configure/Update domain > Verify and save domain - as-is in the above link.
6. After it succeeds, you can remove the hosted file. Microsoft states you don’t need to keep the verification resources after the domain is verified. - https://learn.microsoft.com/en-us/entra/identity-platform/howto-configure-publisher-domain

I hope this is helpful! Do not hesitate to let me know if you have any other questions or clarifications.

Please don't forget to close up the thread here by upvoting and accept it as an answer if it is helpful.

Hi @Enrico Rossini

Thank you for reaching out to Microsoft Q&A.

The issue you are facing occurs due to a combination of expected Azure behavior and validation requirements. Azure expects the file to be hosted at /.well-known/microsoft-identity-association.json, which you have correctly done. However, during verification, Azure may internally attempt to access the file without the .json extension—this is a known portal behavior/bug and can be ignored. The actual failure in your case is not due to file location or naming, but because Azure is unable to validate the content of the file. Specifically, the error “The app id was not found in the json file” indicates that Azure successfully accessed your file but did not find a matching Application (client) ID or could not properly read the file due to strict validation checks such as incorrect headers, redirects, or formatting issues. Azure domain verification is very strict and may fail even if the file is accessible in the browser.

Refer below points to resolve this issue or this is the workaround

Ensure the JSON file contains the correct Application (client) ID Make sure your file is in the exact format below and includes the correct App Registration Client ID:

{
 "associatedApplications": [
 {
 "applicationId": "YOUR_APPLICATION_CLIENT_ID

The Application ID must exactly match the App Registration → Overview → Application (client) ID.

Verify the file is accessible at the exact required path Confirm the file is publicly accessible at: https://<your-domain>/.well-known/microsoft-identity-association.json No authentication or login should be required, and it should open directly in an incognito browser.

Check the Content-Type header is strictly application/json Azure validation fails if the response header is not exact. Ensure:

Content-Type: application/json

Avoid values like application/json; charset=utf-8, as they can cause verification failure.

Ensure there are no redirects or URL rewrites The request must not redirect (for example, HTTP → HTTPS or non-www → www). Azure requires a direct response from the exact URL without any redirection.

Validate using curl or similar tool Run the following command to confirm headers and response:

curl -I https://<your-domain>/.well-known/microsoft-identity-association.json

Ensure you get:

• HTTP 200 OK
• Content-Type: application/json
• No redirects

Check CDN / Proxy / Gateway configurations If you are using services like Cloudflare, Front Door, or Application Gateway, ensure they are not modifying headers, adding caching, or altering the response content.

Workaround: Use DNS-based domain verification If file-based verification continues to fail, you can use DNS verification instead by adding a TXT record in your DNS and verifying the domain in Microsoft Entra ID. This avoids hosting-related issues entirely.