The only way to revoke Spotify API tokens is to delete your account (opens in new tab)

In fairness, that's right about how I feel about the rendering of monospace in HN comments, and how HN commenters continue to use monospace for quoting even knowing how long lines will appear; I'm just a little better at expressing my dissatisfaction.

Same kind of folks who end up yelling at customer service or wait staff for something that's gone wrong.

Yelling isn't productive and it's not going to solve anything. You can totally communicate your frustration without resorting to raising your voice. If anything, making people that distressed is only counterintuitive and counterproductive.

As a user Facebook's approach seems much better. I can't remember specifically what it was but I recently wanted to make a change to my Spotify account (which I've had since it first launched in the UK in 2009). Support told me the only option was to create a new account. This would have meant losing all of the songs I'd saved over the years, all playlists I'd created, and all playlists I was following. I'd also have to make all of the necessary friend connections again to access playlists I was collaborating on. The worst part is that the 'profile' Spotify has built that makes it's recommendations decent for me would be lost so Discover Weekly and recommendations would suck until it had built a new profile. That's a horrible experience for the user.

I believe you can login direct to spotify using your fb credals.

No problem. It might not seem obvious when you build small-mid size backends, because in that scenario you might have an access token stored in your database that's checked each time someone makes a request. Token revocation is as easy as deleting that access token from your database.

Once you start building something at scale, it's harder to revoke tokens instantly. You still need to validate the token on each request, you need to build a highly available, fault tolerant system that can scale with the load of the rest of your application. Usually to reduce this load and improve performance, you'll see two strategies to deal with it:

Caching - check for the access token on the first request, and cache the access token for a certain period of time.

Signed / Encrypted tokens - JWTs are one example. The token contains the user ID, expiration, and other info, and is signed / encrypted. A server can read this, and knowing the signing key, verify the token.

However, if you revoke one of these tokens, it's not instant. A centralized store won't update any of the caches, and a Signed / Encrypted token lives on the client. So for token revocation, you now need to create a cache invalidation scheme, or maintain a blacklist of signed tokens.

While it's still not that hard, it'd hard enough that most teams would rather work on a new feature or something else that's on fire than figuring out token revocation.