MusicKit JS authorize() returns AUTHORIZATION_ERROR "Unauthorized" (no Music User Token) — catalog works

Media Technologies Audio
maurockstar OP
Created
Replies 4
Boosts 0
Views 1k
Participants 3

Hi all — hoping someone has hit this.

Our MusicKit JS (v3) web app calls authorize() and it rejects with AUTHORIZATION_ERROR / "Unauthorized" (no Music User Token is issued), even though the same developer token returns HTTP 200 for catalog requests (/v1/catalog/us/search) — so the token itself is valid.

Setup (all verified):

  • MusicKit JS v3 from js-cdn.music.apple.com/musickit/v3/musickit.js; MusicKit.configure() succeeds, storefront resolves to "us".
  • Developer token is ES256, valid, and includes the origin claim for our exact site origin.
  • Our MusicKit key is enabled for Media Services and tied to a Media ID that has MusicKit enabled.
  • Referrer-Policy: strict-origin-when-cross-origin.
  • Repro: sign in with an active Apple Music subscriber and tap Allow -> authorize() rejects. Reproduces for two subscriber Apple IDs, in Chrome and Edge, with third-party cookies allowed.

Error object: { name: "AUTHORIZATION_ERROR", message: "Unauthorized", isMKError: true }, thrown inside musickit.js during the authorize() flow. The served MusicKit build is a prerelease (3.2526.0-prerelease.x).

We've ruled out the usual suspects on our side (origin claim, referrer policy, token validity, API version, cookies, and portal provisioning). Has anyone resolved this, or is there an additional server-side enablement needed for a team/Media ID to issue web user tokens? Also filed as FB23587284. Thanks!

Answered by DTS Engineer in 896536022

Thanks for the thorough write-up, and for filing FB23587284.

Right now the Feedback is waiting on a sysdiagnose: it has a request to attach one, and that is the step that lets the investigation continue. You can capture it using the sysdiagnose capture directions.

On your question about server-side enablement: I did not find an additional documented enablement step for issuing web user tokens. As described in User Authentication for MusicKit, MusicKit on the Web manages the Music User Token automatically. That requires a valid developer token (which your catalog requests confirm) and a MusicKit-enabled Media ID. Based on your description, that setup is in place, so the documented requirements are met. With authorize() still returning Unauthorized for active subscribers, the behavior is outside what the documentation requires. That is why the sysdiagnose and the Feedback investigation are the right path.

A few things worth checking alongside the sysdiagnose:

  • Confirm your authorize() usage matches the documented pattern. The User Authorization guide shows the minimal call, MusicKit.getInstance() followed by await music.authorize(). Your report covers the configuration in depth but not the calling code.
  • The served build you mention is a prerelease (3.2526.0-prerelease.x). Confirming the behavior on the current stable v3 build would rule out a build-specific issue.
  • The error you have is the wrapped MKError "Unauthorized." Capturing the raw HTTP request and response of the token exchange in the browser Network tab shows the underlying status and body from the authorization endpoint. That is more specific than the MKError and worth including with the Feedback.

Once you have attached a sysdiagnose to your bug, respond here and I'll query the engineering team about it.

Please let me know if there are any questions.

Replies  4
Boosts 0
Views  1k
Participants  3
DTS Engineer OP
Apple
Recommended

Thanks for the thorough write-up, and for filing FB23587284.

Right now the Feedback is waiting on a sysdiagnose: it has a request to attach one, and that is the step that lets the investigation continue. You can capture it using the sysdiagnose capture directions.

On your question about server-side enablement: I did not find an additional documented enablement step for issuing web user tokens. As described in User Authentication for MusicKit, MusicKit on the Web manages the Music User Token automatically. That requires a valid developer token (which your catalog requests confirm) and a MusicKit-enabled Media ID. Based on your description, that setup is in place, so the documented requirements are met. With authorize() still returning Unauthorized for active subscribers, the behavior is outside what the documentation requires. That is why the sysdiagnose and the Feedback investigation are the right path.

A few things worth checking alongside the sysdiagnose:

  • Confirm your authorize() usage matches the documented pattern. The User Authorization guide shows the minimal call, MusicKit.getInstance() followed by await music.authorize(). Your report covers the configuration in depth but not the calling code.
  • The served build you mention is a prerelease (3.2526.0-prerelease.x). Confirming the behavior on the current stable v3 build would rule out a build-specific issue.
  • The error you have is the wrapped MKError "Unauthorized." Capturing the raw HTTP request and response of the token exchange in the browser Network tab shows the underlying status and body from the authorization endpoint. That is more specific than the MKError and worth including with the Feedback.

Once you have attached a sysdiagnose to your bug, respond here and I'll query the engineering team about it.

Please let me know if there are any questions.
bnwtricia OP

hi @maurockstar, did this ever get solved for you? I am having the same problem on the same MusicKit version.

Apple peeps: Seeing the same issue on my new developer account. authorize() rejects with AUTHORIZATION_ERROR right after the user clicks Allow; webPlayerLogout then returns 403 with x-apple-music-user-token: undefined. Catalog requests with the same key work, and the same Apple Account plays fine on music.apple.com.

  • MusicKit JS served: 3.2526.0-prerelease.x
  • Safari 26.5.2 (macOS) and Chrome 137
  • Fails from both http://localhost and a public https origin, with and without an origin claim in the developer token
  • Key created 2026-11-06; still failing more than 24 hours later
  • Example: x-apple-request-uuid 2e09b472-01c7-510a-b4e6-16eda612a7ee (2026-11-06 18:34:23 GMT)

Filed as FB25477648 with a sysdiagnose attached.

I've also contacted Developer Support. Happy to share more details.

DTS Engineer OP
Apple

Thanks for filing FB25477648 with a sysdiagnose, and for including the request UUID and timestamp in your post. I checked on FB25477648 and on FB23587284, the original report in this thread. Both remain open and under investigation. I also added notes to both reports that link them to each other.

If you filed FB23587284, are still seeing this failure, and haven't attached a sysdiagnose, attaching one lets that investigation continue. The sysdiagnose instructions cover each Apple platform.

Please file your own report in Feedback Assistant if you're seeing the same failure and haven't filed one. If you test on a Mac, attach a sysdiagnose captured right after the failure. Post the Feedback number here, and I'll check its status next time I do a sweep of forums posts where I've suggested bug reports.
bnwtricia OP

Update: solved on my side, and it may be worth checking yours @maurockstar. My site sent "Referrer-Policy: no-referrer" on every page. With that policy the authorize.music.apple.com popup gets an empty document.referrer and can't hand the Music User Token back, so authorize() fails with AUTHORIZATION_ERROR "Unauthorized" right after Allow. Changing the header to "Referrer-Policy: strict-origin" fixed it immediately, on the same 3.2526.0-prerelease build. Check your server headers, any <meta name="referrer"> tag in the page, and rel="noreferrer" on links. (Credit to the vibez project, which hit the same problem: github.com/simonepelosi/vibez/issues/182)