3 ms·

This isn't at all directed at this post in particular – but I'm curious, what's with the huge movement towards JWT? I get their use-case, but it seems like most

by ezekg 10y ago

This isn't at all directed at this post in particular – but I'm curious, what's with the huge movement towards JWT? I get their use-case, but it seems like most implementations shoe-horn JWT's to act exactly like access tokens stored within a database. Revoking a JWT doesn't make any sense to me.

awjr 10y ago
I have to agree. A JWT contains within it 'claims' that are the authorization for allowed behaviour against the API. Authentication happens before the JWT is issued. I think the problem is that it's not about issuing just one JWT, you need a 'refresh' token and a 'security' token. The security token expires quickly, but a new security token can be issues using the refresh token which has a long expiry. You can even make the refresh token single use with the action of refreshing the security token returning you a new refresh token. This, however, needs to be handled carefully within the UI as two requests using the same refresh token would invalidate the 'session'. The reasoning is that the api can trust the claims within the security token, but has no need to access external sources to validate the token. The refresh token can have security policies applied to it as well as 'user logged out' checks against the refresh token. This keeps the API requests extremely fast with only an intermittent (once a minute) need to get a new security token.
- eridius 10y ago
  Of course, if your application hits the API less than once a minute, you've now doubled the number of requests it needs to make, because it will need to refresh the token before every call.
donpark 10y ago
I suspect it's mostly cargo-cult thing. JWT itself, however, is a signed-JSON format with detached signature which is very useful well beyond access token use-case. JWT as access token at large scale will require frequent key rotation so inability to revoke becomes a problem but it's not a show stopper because one can work around it using various tactics such as bloom filter I mentioned above.

by ezekg 10y ago

awjr 10y ago

I have to agree. A JWT contains within it 'claims' that are the authorization for allowed behaviour against the API. Authentication happens before the JWT is issued. I think the problem is that it's not about issuing just one JWT, you need a 'refresh' token and a 'security' token. The security token expires quickly, but a new security token can be issues using the refresh token which has a long expiry. You can even make the refresh token single use with the action of refreshing the security token returning you a new refresh token. This, however, needs to be handled carefully within the UI as two requests using the same refresh token would invalidate the 'session'. The reasoning is that the api can trust the claims within the security token, but has no need to access external sources to validate the token. The refresh token can have security policies applied to it as well as 'user logged out' checks against the refresh token. This keeps the API requests extremely fast with only an intermittent (once a minute) need to get a new security token.

eridius 10y ago
Of course, if your application hits the API less than once a minute, you've now doubled the number of requests it needs to make, because it will need to refresh the token before every call.

donpark 10y ago

I suspect it's mostly cargo-cult thing. JWT itself, however, is a signed-JSON format with detached signature which is very useful well beyond access token use-case. JWT as access token at large scale will require frequent key rotation so inability to revoke becomes a problem but it's not a show stopper because one can work around it using various tactics such as bloom filter I mentioned above.