3 ms·

How do Oauth2 providers like Google and Github handle password resets or stale data with JWT tokens? Curious because I was trying to implement JWT for auth, but

by bhl 6y ago

How do Oauth2 providers like Google and Github handle password resets or stale data with JWT tokens? Curious because I was trying to implement JWT for auth, but might switch to sessions now.

bojanz 6y ago
Assuming that the JWT only stores the user_id, and you then load the full user (protecting against stale data), a counter or a timestamp on the user object can be used to control logout. There's a good Go library detailing this approach, along with a blog post: https://github.com/endiangroup/compandauth https://github.com/endiangroup/compandauth https://endian.io/articles/compandauth/ https://endian.io/articles/compandauth/
blahbhthrow3748 6y ago
You basically need to have a revocation list or rely on the expiration time being sufficiently short. JWTs are neat for a lot of things but I don't think they make sense as a replacement for sessions for that reason (where you control the server and the client and you want to authenticate users)
- magicalhippo 6y ago
  Isn't that the point of the refresh tokens? Auth token is short lived, so you get a new one using the refresh token without getting the user involved. But then that gives the auth server a means to deny that request if the user has revoked access? Or am I misremembering?
  - trebecks 6y ago
    yeah, that is what refresh tokens are used for and it works well for access tokens with a short ttl. in practice i have seen access tokens with ttl of a few hours. i think it might be done to cut down on the refresh calls? in that case, if you want to deny requests with a revoked token sooner than the potentially few hours it takes for it to expire, you could keep the set of revoked tokens server side. that feels like a weird place to be in with server side state for stuff that is supposed to be stateless. i guess the revoked set is smaller than the full set of active tokens so maybe that is a win? curious if anyone has experience with this.
    - bhl 6y ago
      > the revoked set is smaller than the full set of active tokens so maybe that is a win Yeah, it seems to me the difference between having a revocation / blacklist and a non-JWT based sessions isn't the number of queries to a redis cache, since each request to the resource server will result in a check first. It's the in-memory size of the cache. I think that clears up my question about the benefits of using JWT. Thanks! :)
    - magicalhippo 6y ago
      > in practice i have seen access tokens with ttl of a few hours The JWT tokens we get for m2m from Maskinporten[1] have a TTL of a couple of minutes. No refresh tokens though, I guess they figure it doesn't make much difference since the "user" is a machine so no hassle just sending a full request again. [1]: https://difi.github.io/felleslosninger/maskinporten_protocol_jwtgrant.html https://difi.github.io/felleslosninger/maskinporten_protocol...
  - dchest 6y ago
    http://cryto.net/~joepie91/blog/2016/06/19/stop-using-jwt-for-sessions-part-2-why-your-solution-doesnt-work/ http://cryto.net/~joepie91/blog/2016/06/19/stop-using-jwt-fo...

by bhl 6y ago

How do Oauth2 providers like Google and Github handle password resets or stale data with JWT tokens? Curious because I was trying to implement JWT for auth, but might switch to sessions now.

bojanz 6y ago

Assuming that the JWT only stores the user_id, and you then load the full user (protecting against stale data), a counter or a timestamp on the user object can be used to control logout. There's a good Go library detailing this approach, along with a blog post: https://github.com/endiangroup/compandauth https://github.com/endiangroup/compandauth https://endian.io/articles/compandauth/ https://endian.io/articles/compandauth/

blahbhthrow3748 6y ago

You basically need to have a revocation list or rely on the expiration time being sufficiently short. JWTs are neat for a lot of things but I don't think they make sense as a replacement for sessions for that reason (where you control the server and the client and you want to authenticate users)

magicalhippo 6y ago
Isn't that the point of the refresh tokens? Auth token is short lived, so you get a new one using the refresh token without getting the user involved. But then that gives the auth server a means to deny that request if the user has revoked access? Or am I misremembering?
- trebecks 6y ago
  yeah, that is what refresh tokens are used for and it works well for access tokens with a short ttl. in practice i have seen access tokens with ttl of a few hours. i think it might be done to cut down on the refresh calls? in that case, if you want to deny requests with a revoked token sooner than the potentially few hours it takes for it to expire, you could keep the set of revoked tokens server side. that feels like a weird place to be in with server side state for stuff that is supposed to be stateless. i guess the revoked set is smaller than the full set of active tokens so maybe that is a win? curious if anyone has experience with this.
  - bhl 6y ago
    > the revoked set is smaller than the full set of active tokens so maybe that is a win Yeah, it seems to me the difference between having a revocation / blacklist and a non-JWT based sessions isn't the number of queries to a redis cache, since each request to the resource server will result in a check first. It's the in-memory size of the cache. I think that clears up my question about the benefits of using JWT. Thanks! :)
  - magicalhippo 6y ago
    > in practice i have seen access tokens with ttl of a few hours The JWT tokens we get for m2m from Maskinporten[1] have a TTL of a couple of minutes. No refresh tokens though, I guess they figure it doesn't make much difference since the "user" is a machine so no hassle just sending a full request again. [1]: https://difi.github.io/felleslosninger/maskinporten_protocol_jwtgrant.html https://difi.github.io/felleslosninger/maskinporten_protocol...
- dchest 6y ago
  http://cryto.net/~joepie91/blog/2016/06/19/stop-using-jwt-for-sessions-part-2-why-your-solution-doesnt-work/ http://cryto.net/~joepie91/blog/2016/06/19/stop-using-jwt-fo...