I'm writing an application that interfaces with Apple Music API, and up until this point, all of my API calls were non-personalized, such as searching for a catalog song or artist. The typical flow would be the client app searches for something by hitting my server's "search" endpoint, then my server (where the developer tokens are stored) would actually make the request to the AM API, and then pass back the search results to the client.
However, I now need to make some personalized API requests, like getting a user's playlists. This requires a user token to be included in the request along with the developer token. The problem is, to request a user token, it seems I need to use requestUserToken, which would pull up a prompt on the device to authorize my app with Apple Music, and requires a developer token as an argument.
It seems insecure to have developer tokens lying around on the client side, as they can be used to make any request directly, and a malicious client could theoretically spam a bunch of requests with it and cause the rate limit to go into effect.
Am I misunderstanding something in this protocol, or do I just need to swallow the risks and tell my server to pass along the developer token to the client?
