Skip to content
This repository has been archived by the owner on May 26, 2020. It is now read-only.

Long running refresh tokens #94

Closed
wants to merge 2 commits into from

Conversation

fxdgear
Copy link

@fxdgear fxdgear commented Apr 2, 2015

Taking an example of what Auth0 has done: https://auth0.com/docs/refresh-token I've tried to implement a similar process.

This allows for a client to request refresh tokens. These refresh tokens do not expire.
They can be revoked (deleted). When a JWT has expired, it's possible to send a request
with the refresh token in the header, and get back a new JWT. This allows for the client
to not have to store username/passwords. So, if the client gets a responce about an expired token
the client can automatically make a call (behind the scenes) to delegate a new JWT using
the stored refresh token. Thus keeping the 'session' active.

Note This is mostly for discussion right now. But I have tested the views only (and by sideffect the serializers and authentication backend). I have not had time yet to try it on python3 though.

@fxdgear
Copy link
Author

fxdgear commented Apr 2, 2015

Possible suggestion: Move this long running refresh token into it's own subdir/sub-app. Like how DRF has done with authtoken. This would make using the long running refresh token optional, and not create a DB table if not necessary.

This allows for a client to request refresh tokens. These refresh tokens do not expire.
They can be revoked (deleted). When a JWT has expired, it's possible to send a request
with the refresh token in the header, and get back a new JWT. This allows for the client
to not have to store username/passwords. So, if the client gets a responce about an expired token
the client can automatically make a call (behind the scenes) to delegate a new JWT using
the stored refresh token. Thus keeping the 'session' active.

moving everything to it's own sub dir, so that the refresh token functionality can be optionally installed.
@fxdgear fxdgear force-pushed the long_running_refresh_tokens branch from a337ee0 to 77fcc13 Compare April 2, 2015 17:27
@jpadilla
Copy link
Owner

jpadilla commented Apr 4, 2015

@fxdgear how is this different or better than the already existing RefreshJSONWebToken that was implemented a while back?

@fxdgear
Copy link
Author

fxdgear commented Apr 4, 2015

If the JWT expires in the current implementation then you have to sign in again.

This will allow an app to be signed in "forever" without having to a) store the username/password and b) be online 100% of the time to keep the JWt active.

@jpadilla
Copy link
Owner

jpadilla commented May 3, 2015

@fxdgear haven't forgotten about this. I guess the only thing this might be need is docs and perhaps separating it into a subapp like #91.

@auvipy
Copy link

auvipy commented Dec 1, 2015

@fxdgear This branch has conflicts that must be resolved

@fxdgear
Copy link
Author

fxdgear commented Dec 1, 2015

closing in favor of #123

@fxdgear fxdgear closed this Dec 1, 2015
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants