Title: MusicKit Web v3 authorize() fails with AUTHORIZATION_ERROR after Allow — Windows Chrome/Edge (FB25267497)

Media Technologies Audio
music_cat OP
Created
Replies 2
Boosts 0
Views 246
Participants 2

Hello Apple engineers and fellow developers,

I am developing CloudMusic Bridge, a Windows desktop music application integrating the official MusicKit Web v3 SDK.

MusicKit initialization succeeds, but authorize() consistently rejects with AUTHORIZATION_ERROR after the user clicks Allow in Apple's official authorization window.

Environment

  • Windows, Google Chrome and Microsoft Edge
  • MusicKit Web v3 from Apple's official CDN
  • Local HTTPS origin: https://localhost:4318
  • Valid ES256 developer token with a matching origin claim
  • MusicKit-enabled Media ID and associated Media Services key
  • Active Apple Music subscription, with full-song playback working on music.apple.com
  • Catalog API requests succeed (HTTP 200)
  • Actual MusicKit SDK build: UNKNOWN

Reproduction

I created a standalone minimal reproduction that loads MusicKit, initializes it, obtains the instance and invokes instance.authorize() directly from a user click.

The user signs in and clicks Allow, but the authorization Promise rejects.

I also tested a separate page that explicitly allows https://play.itunes.apple.com in both CSP connect-src policies.

This eliminated the previously observed document CSP violations during the comparison, but authorization still failed with AUTHORIZATION_ERROR after approximately 46.6 seconds.

The application did not reach its 120-second timeout.

Questions for Apple DTS

  1. How can I verify that my browser is loading the current supported stable MusicKit Web v3 build?
  2. Is there any additional developer configuration required for web authorization?
  3. How can I safely identify the underlying authorization exchange failure?
  4. Since this reproduces on Windows, what diagnostics should I provide instead of macOS sysdiagnose?
  5. Could an Apple engineer help investigate my existing report, FB25267497?

I have already contacted Apple Developer Support and was directed to the Developer Forums for SDK-related technical assistance.

I can provide a sanitized minimal reproduction and diagnostic timeline.

Thank you for your help.

Answered by DTS Engineer in 912464022

Thanks for the careful write-up and the minimal reproduction, and for filing FB25267497.

On loading the current build, Getting Started documents one script URL, Apple's hosted https://js-cdn.music.apple.com/musickit/v3/musickit.js. The documentation doesn't describe a way to check which build that URL served.

On configuration, the MusicKit.configure() reference lists developerToken and app.name as required, and app.build, app.icon, bitrate, and storefrontId as optional. It doesn't describe any other configuration for authorization.

On the failure itself, the MKError reference describes AUTHORIZATION_ERROR only as "Error code indicating the authorization was rejected," and documents no further detail. The MusicKit Instance reference documents authorize() as resolving with undefined when authorization fails or is canceled, rather than rejecting. Include the rejection you see in your report.

One variable you can remove is the origin claim. Generating Developer Tokens lists it as "Optional, but recommended for web clients." The documentation doesn't say whether a local origin such as https://localhost:4318 is acceptable. Trying a token without the claim would show whether it's involved.

On diagnostics, the sysdiagnose instructions cover Apple platforms only. For the report, the browser's console output and a network log of a failed authorization would show the exchange. Remove the developer token and any user tokens before attaching them.

I checked on FB25267497, and it remains open and under investigation. Adding the console output, the network log, and the result without the origin claim to the report gives engineering the most to work with.

Separately from FB25267497, please consider filing an enhancement request using Feedback Assistant for documentation changes. In it, you could ask for MusicKit on the Web documentation that covers:

  • Identifying the loaded build
  • Using a local origin in the developer token
  • Collecting diagnostics on other platforms

Please note that filing an enhancement request does not guarantee Apple will add any requested functionality to Apple products in the future. However, with that said, filing an enhancement request is a good way to get your ideas in front of the folks who make decisions about that sort of thing. Bug Reporting: How and Why? has tips on creating your report.

Replies  2
Boosts 0
Views  246
Participants  2
DTS Engineer OP
Apple
Recommended

Thanks for the careful write-up and the minimal reproduction, and for filing FB25267497.

On loading the current build, Getting Started documents one script URL, Apple's hosted https://js-cdn.music.apple.com/musickit/v3/musickit.js. The documentation doesn't describe a way to check which build that URL served.

On configuration, the MusicKit.configure() reference lists developerToken and app.name as required, and app.build, app.icon, bitrate, and storefrontId as optional. It doesn't describe any other configuration for authorization.

On the failure itself, the MKError reference describes AUTHORIZATION_ERROR only as "Error code indicating the authorization was rejected," and documents no further detail. The MusicKit Instance reference documents authorize() as resolving with undefined when authorization fails or is canceled, rather than rejecting. Include the rejection you see in your report.

One variable you can remove is the origin claim. Generating Developer Tokens lists it as "Optional, but recommended for web clients." The documentation doesn't say whether a local origin such as https://localhost:4318 is acceptable. Trying a token without the claim would show whether it's involved.

On diagnostics, the sysdiagnose instructions cover Apple platforms only. For the report, the browser's console output and a network log of a failed authorization would show the exchange. Remove the developer token and any user tokens before attaching them.

I checked on FB25267497, and it remains open and under investigation. Adding the console output, the network log, and the result without the origin claim to the report gives engineering the most to work with.

Separately from FB25267497, please consider filing an enhancement request using Feedback Assistant for documentation changes. In it, you could ask for MusicKit on the Web documentation that covers:

  • Identifying the loaded build
  • Using a local origin in the developer token
  • Collecting diagnostics on other platforms

Please note that filing an enhancement request does not guarantee Apple will add any requested functionality to Apple products in the future. However, with that said, filing an enhancement request is a good way to get your ideas in front of the folks who make decisions about that sort of thing. Bug Reporting: How and Why? has tips on creating your report.

DTS Engineer OP
Apple

Thanks for running the test without the origin claim. Please add that result to FB25267497, along with the roughly 70 seconds between your click and the rejection.

For the console output, save the messages your browser's developer tools show during one failed authorization. For the network log, export the requests from your click through the rejection.

Before attaching either file, remove the developer token, any Music User Token, cookies, and authorization headers. A network log can include all of these. Then attach both files to FB25267497 rather than posting them here.