4 ms·

I wouldn't be a fan of adding that kind of permissions to JWTs. Permission authorization should be stored in the server. JWTs should be for authentication. Pl

I wouldn't be a fan of adding that kind of permissions to JWTs. Permission authorization should be stored in the server. JWTs should be for authentication. Plus for some things you want to invalidate based on how recently they have interacted (IE bank logs you out if you haven't clicked/typed anything for 5 minutes) and you can't represent that without server state.

anderspitman 7y ago
> I wouldn't be a fan of adding that kind of permissions to JWTs. Permission authorization should be stored in the server. JWTs should be for authentication. I don't necessarily disagree, but I'm going to push back a bit for the sake of discussion. I think it's worth questioning why JWTs should only be for authentication. Size is the only compelling argument I'm aware of, and I think there's a lot of cases where it wouldn't be a problem in practice. Would have to be measured. What would you think of providing 2 interfaces to the auth server. You could return an authorized token like I mentioned, or you could return a token which is only authenticated. Then the app server ("client" in oauth parlance) would make a request directly to the auth server to get the actual authorization token. So app developers could choose whether to accept authorized tokens, or only authenticated tokens if they want more control over security/token size. > Plus for some things you want to invalidate based on how recently they have interacted (IE bank logs you out if you haven't clicked/typed anything for 5 minutes) and you can't represent that without server state. I don't see a problem here. I'm fine with the app server having state. In this case it would simply mark that token as invalid.
- lsiebert 7y ago
  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.

anderspitman 7y ago

> I wouldn't be a fan of adding that kind of permissions to JWTs. Permission authorization should be stored in the server. JWTs should be for authentication. I don't necessarily disagree, but I'm going to push back a bit for the sake of discussion. I think it's worth questioning why JWTs should only be for authentication. Size is the only compelling argument I'm aware of, and I think there's a lot of cases where it wouldn't be a problem in practice. Would have to be measured. What would you think of providing 2 interfaces to the auth server. You could return an authorized token like I mentioned, or you could return a token which is only authenticated. Then the app server ("client" in oauth parlance) would make a request directly to the auth server to get the actual authorization token. So app developers could choose whether to accept authorized tokens, or only authenticated tokens if they want more control over security/token size. > Plus for some things you want to invalidate based on how recently they have interacted (IE bank logs you out if you haven't clicked/typed anything for 5 minutes) and you can't represent that without server state. I don't see a problem here. I'm fine with the app server having state. In this case it would simply mark that token as invalid.

lsiebert 7y ago
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.