New Web (API) Foundations (Part Six)

Published: 2021-10-25

Author: Teddi

Last post we covered authentication and how it was effectively split three ways depending on the action the end-user was trying to do. Now we’re covering authorization which is conceptually far simpler! We’ll begin by splitting authorization in two, what we consider “personal” authorization and “administrative” authorization. These are concepts only and are implemented in a logical fashion as opposed to a physical one.

As I mentioned in Part 5, privacy to me is an incredibly important thing in that I believe in the right to fully control your data: organizations and groups should make a best-effort attempt at implementing controls which gives this control. In the event controls can’t easily be granted then the assumption should always be that the user doesn’t want their information shared and it should be withheld at all costs with exception of the user directly using it themselves.

This is exactly how our API functions: if a key hasn’t been flagged as what we call a “system” key (bit of a misnomer but hey) then any API key generated by default is unable to query data player-specific data outside of the account it was generated against. Admittedly our behaviour around how we relay this isn’t the most consistent and at some point I may tighten this up but what is true is that you end up with one of two responses - a 403 or we just return your data instead. Furthermore because JWTs use the same underlying permission system it means they’re subject to the exact same rules! In fact because we only ever want JWTs to be used by players in game it means that we set the permissions of every JWT as it passes through to be one that does not have system access. Nice and easy!

So outside of player privacy we have a few more key types and these are incredibly boring. These permission flags mostly deal with things such as can a key issue JWTs or can a key wipe out cache keys and so on. Ultimately we don’t want the average API key (or JWT) to access what are administrative actions even though the routes aren’t actively known and at the end of the day - a lock only works to keep honest people out.

There’s one last authoritative flag which exists - API key rate limiting. This is less of a flag and more just a “once you’ve made this many queries, you gotta wait until reset”. While not strictly a flag in a binary sense it still acts in an authoritative way and not an authentication method because your credentials are correct - we just can’t let you see the data for the time being.

That sums up authorization and was a fair bit smaller this time! Next post: Summary?