Long running refresh tokens #123
Conversation
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.
and choose constraint for user and app together
The delegation endpoint
is a `POST`, with the following body.
```json
{
"client_id": "YOUR_CLIENT_ID",
"grant_type": "urn:ietf:params:oauth:grant-type:jwt-bearer",
"refresh_token": "your_refresh_token",
"api_type": "app"
}
```
| @@ -0,0 +1,23 @@ | |||
| # -*- coding: utf-8 -*- | |||
| from __future__ import unicode_literals | |||
There was a problem hiding this comment.
Would probably be best to squash these migrations?
There was a problem hiding this comment.
Yes, but I would like to do it once @jpadilla considers it ready for merging. Just in case some amendments are still necessary on the Model.
I will add it in the description as a reminder.
|
This looks really good, guys. Should we keep around our current refresh feature or should this simply replace that and be the preferred way for token refresh? As with #123 it'd be great if we could chat and figure out if we can come up with a demo for this feature. |
|
@jpadilla so I think that both have a usecase. In the sense of a browser, the refresh token that exists currently is a better option. The idea is that a browser shouldn't be storing the refresh tokens (imo). And similarly a native app should NOT be storing a users password. |
|
I think the current refresh feature would still be useful for certain applications but we should make sure to distinguish the two in the documentation One thing that's bugging me is, should we consider an option to set expiration time on these tokens? (e.g. 14 days or something). One application I was thinking this refresh token would solve (and the existing one does not) is emulating browser sessions and keeping a user logged in (even if they haven't checked in in a while). But storing an permanent refresh token isn't that appealing. |
|
I would recommend NOT using this for browser sessions. This would require the browser to store long running refresh token. Which imo is a bad idea. This is more useful in the case of an iPhone app or a native app or some sort of CLI interface. |
|
Yes that's true, XSS would be an issue. This would be indeed be very useful for mobile/native apps though. What do you think about an optional expiration time though? |
|
@alvinchow86 Expiration can be implemented by deleting the |
|
@jpadilla
|
|
Will this be merged soon? |
|
hey btw I made a demo for the blacklist token feature, maybe it could be used as the general demo for this app if one doesn't exist already? lmk if anyone wants to access it (uses ember-cli on frontend) https://jwtdemo-frontend.herokuapp.com/login |
|
I honestly think that this would make a great third party package on its own. It's more ambitious than what this package was meant to be. If @ticosax or anyone wants to pick this up go right ahead. Also living apart will help with maintenance. Thanks to everyone who worked hard on this. |
|
Fair enough. |
|
@ticosax awesome! |
|
👍
|
|
This project is pretty much the de facto standard when using JWTs with the Django rest framework. @jpadilla Can I ask why this was decided to be split into another project when refresh tokens seem to be a major part of using JWTs? Especially when most articles and stackoverflow answers recommend using them? I feel that this split will cause the new package to gain far less exposure, which is so critical with security applications. Does anyone know if DRF is thinking about natively supporting JWTs? |
|
I agree with @Darkman |
related to #117 and #94
But change the way we obtain a new JWT. Compare to #94, now the implementation try to be more compliant with https://auth0.com/docs/refresh-token
The delegation endpoint is a
POST, with the following body.{ "client_id": "YOUR_CLIENT_ID", "grant_type": "urn:ietf:params:oauth:grant-type:jwt-bearer", "refresh_token": "YOUR_REFRESH_TOKEN", "api_type": "app" }instead of being a
POST+ empty body + the refresh token passed inAuthorizationheader./cc @fxdgear
TODO before merging: