4 ms·

But what's the benefit of authorized tokens over authorization being server side? I think it's best practice not to trust client data. It seems like a potentia

But what's the benefit of authorized tokens over authorization being server side? I think it's best practice not to trust client data. It seems like a potential fail point that might even allow privilege escalation depending on developer configuration (and we are talking about rolling your own auth, so that's a possible concern). You have to store it on the server anyway (so the system can change it asynchronously without the client being online or display a user's permissions to an admin, etc), why duplicate it when you can check it on the server? It also seems like a source of increased bandwidth costs, which is maybe what you meant by size. Even if it doesn't cost you, increasing the bandwidth a client needs for an app isn't user friendly, especially for mobile.

anderspitman 7y ago
The benefit is decoupling the app server from the auth server. If all of the authorization privileges are tracked by the auth server, it becomes the single source of truth. It also makes it easier to switch your app to a different auth server provider (or even accept auth from a list of different ones). If you have a whitelist of auth providers for your app, your users could all pick a different one, and you'd only have to implement a single auth protocol. You could even imagine allowing users to host their own auth server, and providing a way for them to register it with your app.