WNS Push Notification Failing — Microsoft Store Package SID and App Registration Mismatch

This happens often..

Hi Dinesh Kanna P,

The issue you are running into with WNS rejecting your push notifications is due to a mismatch between the identity provisioned by the Microsoft Store and the Azure App Registration you created manually.

To answer your specific questions:

1. Can WNS work with a personal Microsoft account? Yes, it can. WNS does not require an organizational or enterprise account. As long as the app is correctly set up in the Partner Center and the credentials match, WNS will accept the tokens.
2. How do I correctly link the Microsoft Store Package SID with the Azure App Registration? You actually should not manually create a separate Azure App Registration. Instead, you need to use the one that Partner Center provisions for you automatically. To do this:

• Go to the Partner Center and open your app.
• Navigate to Product management → WNS/MPNS.
• Click on the App Registration portal link on that page. This will directly open the Azure App Registration that is officially linked to your store app.
• Create your Client Secret inside that specific App Registration.
• For your OAuth request, use the Package SID from Partner Center as the client_id, and the newly created secret as the client_secret.

3. Is there a way to update the Package App ID in an existing app registration to match? No, there is no supported way to force a manually created Azure App Registration to link to an existing Store identity. You should abandon the App Registration you created manually and follow the steps in Question #2 to use the auto-linked one.
4. Should WNS credentials come from Partner Center or Azure Portal? They come from both, but they are part of the same linked identity:

• The Package SID (client_id) comes from Partner Center.
• The Client Secret (client_secret) comes from the linked App Registration in the Azure Portal.

5. Does Azure Notification Hubs avoid this mismatch issue entirely? No it does not. Azure Notification Hubs is just an abstraction layer for sending notifications; you still need to provide Notification Hubs with a valid Package SID and matching Client Secret for it to be authorized to push via WNS.

Try discarding your manual App Registration, use the App Registration link directly from the Partner Center WNS/MPNS page to generate a new secret, and try your OAuth request again. If you still receive an invalid_client error after doing this, it may be a backend provisioning issue. At that point, you should open a support ticket with Partner Center providing your Store Product ID and Package SID so they can refresh the WNS registration.

1. WNS can be used with an app that is registered in Microsoft Store and has valid WNS credentials. The context does not state any restriction that WNS requires an organizational account instead of a personal Microsoft account; what matters is that the app is correctly created in Partner Center and the WNS credentials (Package SID and secret) are valid and recognized by WNS.
2. The Microsoft Store Package SID and the cloud service credentials must match exactly what WNS expects. The cloud service authenticates to WNS by sending an OAuth token request to https://login.live.com/accesstoken.srf with:
   • grant_type=client_credentials
   • client_id = the Package Security Identifier (SID) assigned when the app was registered with the Microsoft Store
   • client_secret = the secret key created for that same app registration
   • scope=notify.windows.com
   These values must come from the same app registration that Partner Center created for the Store app. If WNS returns an error like invalid_client or indicates a mismatch, it typically means the Package SID or secret being used does not match what is provisioned on the WNS backend for that Store app. The correct linkage is:
   • Create the app in Partner Center (Store).
   • From Product management → WNS/MPNS → App Registration portal, open the corresponding app registration in Azure.
   • On that registration, create the client secret.
   • Use that Package SID (client_id) and that secret (client_secret) in the OAuth request.
   This ensures the Store identity and the Azure app registration are the same object, provisioned by Partner Center, and WNS will accept the token if everything matches.
3. The context does not describe a supported way to change or update the Package App ID (Package SID) of an existing app registration to match a different Store identity. The supported pattern is to:
   • Start from the Store app in Partner Center.
   • Use the WNS/MPNS → App Registration portal link so that Partner Center provisions and links the Azure app registration for that Store app.
   If the current Azure app registration was created separately and is not the one provisioned via Partner Center, it will not match the Store Package SID, and WNS will reject tokens that use that mismatched identity.
4. WNS credentials originate from the Store/Partner Center app and its linked app registration:
   • Partner Center provides the Package SID and exposes the WNS/MPNS section.
   • The App Registration portal link from Partner Center opens the Azure app registration where the client secret is created.
   Both are part of the same identity:
   • Package SID (from Partner Center / Product Identity) → used as client_id.
   • Client secret (from the linked Azure app registration) → used as client_secret.
   WNS expects these to be consistent. Using an arbitrary Azure app registration that is not linked via Partner Center will cause the mismatch being observed.
5. Azure Notification Hubs does not remove the requirement for correct WNS credentials. For UWP/Windows apps, Notification Hubs still requires valid WNS credentials (Package SID and secret) configured on the hub. Those credentials must come from the same Store app registration and its linked app registration as described above. Notification Hubs is an additional abstraction for sending notifications, but it still depends on WNS being correctly configured and recognizing the app’s credentials.

If WNS continues to return errors even when using the Package SID and secret from the Partner Center–provisioned registration, this can indicate a backend provisioning issue. In such cases, opening a support request with Partner Center support and providing the Package SID, Store Product ID, and the exact OAuth request and error is the recommended path so that the WNS registration can be verified and, if necessary, refreshed.

References:

• Push notification service request and response headers (Windows Runtime apps)
• Tutorial: Send notifications to Universal Windows Platform apps using Azure Notification Hubs
• Push notification support for device management
• Troubleshooting WNS push notifications
• Troubleshooting push notifications
• Onboarding to cross-device experiences for Microsoft Graph notifications (deprecated)
• WNS OAuth token request returns “invalid_client_id” for Package SID provisioned via Partner Center - Microsoft Q&A