This is just a simple script I've written while I was trying to find a way to implement Spotify public playlists into my last project I've published here: https://news.ycombinator.com/item?id=36496644
It works by using an endpoint that returns a script filled with credentials for anonymous browsing. This way you can get accessToken and clientID to use with the Spotify Web API.
Interesting, i've never expected Spotify to put the access token in plain text in a script tag and they also set the id to "session".
It's true, that this is not really important, since it's an anonymous token which is generated probably based on a session cookie, but they could have encrypted the json
That just shifts the problem, because then you only need the encrypted token instead of the cookie within it.
This is a fundamental limitation of client-side authentication: it's only enforceable insofar as the browser wants to enforce it. You can protect your token in browser memory from pages on other origins, by relying on well-known behavior of the same origin policy sandbox. But you can't protect it from a modified script on your own page, or an alternative client (like curl) that fetches from the API directly and has no same origin policy.
This comes up all the time, like when Snapchat wants to prevent unauthorized API usage but needs to ship a key in the client bundle, or when Google Maps wants to rate limit requests from an origin. Anyone with root (or really any external observer of the client sandbox) will always be able to obtain the key, or change what they do with it. So Snapchat can pin its HTTPS requests, but users can disable pinning on the client. And Google can reject requests from an origin that doesn't match the provided site key, but only for requests sent from a browser that enforces the same origin policy.
In most cases these limitations are "good enough," but front end devs can sometimes get careless and store what should be a server side secret on the client side. This is why products often have a "site key" and an API secret - they have distinct purposes because the site key should be assumed public.