Add some method that needs authorization

[calebmer]

Currently, all the API methods are unauthorized which means we haven’t yet needed to figure out how authorization should be implemented. That needs to be done…

[baruchadi]

The way I've done it in my previous app is some sort of a controller HOC i.e. withAuthentication(YourScreenComponent) that would check if you are authorized to access that page. usually we add a second variable for specific access levels i.e. admin level vs non-admin.

is that what you are talking about?

[calebmer]

Right now I’m thinking at the API level. Eventually, we will need something like that for the UI though. Like an API.account.updateDisplayName() method that requires you to be authorized to update your display name.

[baruchadi]

can we derive user access level based on their auth token?

anonymous = -1
reg user = 0
pro user =1
admin =9

for example, and then those API end points would gather the auth token (JWT?), check what access level you have, and return access denied if your access level is less than the one required.

updateDisplayName for example will only happen if we can derive that your access level>=0

removing an account that isn't yours, would require you to be access level >= 9

requesting premium content would require you be level>=1

etc. you get the point.

[calebmer]

Right now, the endpoints don’t even know about auth tokens so gotta do that first.

Generally, I don’t like putting a bunch of information about what a user does and does not have access to in their auth token because that can grow pretty quickly. If a user is an admin, what are they an admin of? An admin of an individual DM group, an admin of a community, an admin of a single topic in that community?

As product requirements grow there’s this desire to add more to the access token so they can just grow and grow. I’d prefer to be picky about what goes inside the access token. You can derive a lot of permission information if you know their account ID.

[calebmer]

There’s a great episode of the Bike Shed where host Chris Toomey and his guest talks about their negative experiences with JWTs. They mostly ascribe the issue to JWTs carrying around too much information and so they get out of sync with the core data layer.

Bike Shed episode 184 at ~19:48