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!
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.