Added an optional endpoint that can refresh a token. This can be useful for a webapp to try to keep a user logged in without having to re-enter their password constantly. Got the idea from this post https://auth0.com/blog/2014/01/27/ten-things-you-should-know-about-tokens-and-cookies/

Basically, if JWT_ALLOW_TOKEN_RENEWAL is True, then an extra field orig_iat (stands for original issue at time) is stored on the returned JWT token. You can then pass the token to the RefreshJSONWebToken view, and if orig_iat hasn't yet expired, you get a token with a refreshed expiration time (but with the same orig_iat, so you can only do refreshes up to some time limit, specified in JWT_TOKEN_RENEWAL_LIMIT). Getting a brand new token (by passing in username/password) will return a completely new orig_iat though.

I also added a new handler, jwt_get_user_id_from_payload, that lets you specify how the user_id field is stored. Since it's possible for the custom payload handler to change how the user id is stored, it seems to make sense to have a way to retrieve it too.

Feedback welcome (there are some things that could probably be cleaned up). I didn't add tests yet but if there is interest in this PR I will write some (I did write a number of tests in my application that uses this, so I am reasonably confident it works).

I'm not sure if this is an issue or just because of the implementation, but I was using middleware to log user_id against records being edited, and I couldn't get request.user at the middleware level (and so of course request.user.is_authorized() returned False).

The middleware was the last one on the list, and authorization was working (I would get a 403 requesting assets without my token header). I tried putting 'rest_framework_jwt.authentication.JSONWebTokenAuthentication' at the top of DEFAULT_AUTHENTICATION_CLASSES, and also making it the only item in the tuple; neither worked.

I've managed to work around my issue by accessing the header and using the tools directly in the app to retrieve the user; essentially I copied chunks of your code into my middleware, but I thought you should know :)

If you're interested, here's the middleware:

from django.db.models import signals
from django.utils.functional import curry
from django.utils import timezone
from threading import local

import jwt
from rest_framework.authentication import get_authorization_header
from rest_framework_jwt.settings import api_settings
from django.conf import settings
try:
    from django.contrib.auth import get_user_model
except ImportError:  # Django < 1.5
    from django.contrib.auth.models import User
else:
    User = get_user_model()

_user = local()

class AuditMiddleware(object):
    def process_request(self, request):
        if not request.method in ('GET', 'HEAD', 'OPTIONS', 'TRACE'):
            if hasattr(request, 'user') and request.user.is_authenticated():
                user = request.user
            else:
                user = self.get_user_from_auth_header(request)
                if user is not None:
                    request.user = user

            _user.value = user

            mark_whodid = curry(self.mark_whodid, _user.value)
            signals.pre_save.connect(mark_whodid,  dispatch_uid = (self.__class__, request,), weak = False)

    def process_response(self, request, response):
        signals.pre_save.disconnect(dispatch_uid =  (self.__class__, request,))
        return response

    def mark_whodid(self, user, sender, instance, **kwargs):
        # user logging here

    def get_user_from_auth_header(self, request):
        try:
            auth_keyword, token = get_authorization_header(request).split()
            jwt_header, claims, signature = token.split('.')

            try:
                payload = api_settings.JWT_DECODE_HANDLER(token)
                try:
                    user_id = api_settings.JWT_PAYLOAD_GET_USER_ID_HANDLER(payload)

                    if user_id:
                        user = User.objects.get(pk=user_id, is_active=True)
                        return user
                    else:
                        msg = 'Invalid payload'
                        return None
                except User.DoesNotExist:
                    msg = 'Invalid signature'
                    return None

            except jwt.ExpiredSignature:
                msg = 'Signature has expired.'
                return None
            except jwt.DecodeError:
                msg = 'Error decoding signature.'
                return None
        except ValueError:
            return None

From django-rest-framework v3.2, any attempts to access request.DATA will raise a NotImplementedError with the following message:

request.DATA has been deprecated in favor of request.data since version 3.0, and has been fully removed as of version 3.2.

You can see the change commit here. The error originates here in views.py.

Note that the request.data property appears to have been added in django-rest-framework v3, so simply changing request.DATA to request.data may make this package incompatible with earlier versions.

This branch takes a slightly different approach to 1.10/3.4 support than #252. It includes:

• Updated documentation indicating change in support.
• Add 1.10 and 3.4 to the Travis build matrix and tox file.
• Consolidates the test views into tests/urls.py. 1.10 wasn't working with urlpatterns in the test_views and test_authentication files.
• Tests the is_active behavior for the pre-1.10 ModelBackend and uses the new AllowAllUsersModelBackend to test the similar behavior for 1.10.
• Turns on verbose for tox execution to show what is skipped for Travis builds.

There is one oddity in this branch that I can't really explain well. test_jwt_login_custom_response_json did a check for the username with:

self.assertEqual(response.data['user'], self.username)

That data did not exist under 1.10 and I don't understand why. Someone with a bit more history with the project might want to check if that's ok or a behavioral regression that needs to be fixed first.

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 in Authorization header.

/cc @fxdgear

TODO before merging:

• [ ] provide a squashed migration

If authenticating using a recent JWT, the request fails with

{"detail": "Invalid payload"}

in case a field is empty (tested here with user account that was lacking an email address)

A new configuration 'JWT_AUTH_COOKIE' has been added. If it set to None (the default), everything works the same.

It can be set to a string to use as the name of the cookie that can be used to carry the token. Note the 'Authorization' header is still accepted as the primary method, but it falls back to the designated cookie if present.

When a token is requested and 'JWT_AUTH_COOKIE' is set, the response will set the given cookie with the token string.

Fix #120

I'm using all the default settings (including the default URLS), and using CURL to refresh the token but I get the following error:

{"non_field_errors":["orig_iat field is required."]}

Any idea why this error is occurring?

This PR adds a verification view: verify_jwt_token, which checks if a JWT POSTed to it is valid and that the user exists.

Much of the functionality is the same as the existing refresh view and serializer. I abstracted out the majority of the shared serializer logic to maximise DRYness. There are several other ways this could be implemented, however.

I added tests for the new view and moved a test which was more relevant to this functionality from the refresh view tests.

Suggestions for improvements welcome! If the serializer implementation is ok, it could probably use some unit tests.

Trying to get an new token, with an 'expired' token results in an signature error. The token is decoded with verification of 'exp' claim. Only the orig_iat claim should be verified in this case.

Problem is the JWT_DECODE_HANDLER does not have an option to disable exp verification. Changing the default handler would be an backwards incompatible change... not sure how you guys would want to handle that. So in this pull it has it's own call to jwt.encode...

Fixes #249

I am stuck with the JWT, can any one tell me how can I get user ID along with token.

My url.py :

from webservices import views

router = routers.DefaultRouter()
router.register(r'api/users', views.UserViewSet)


urlpatterns = [
url(r'^admin/', include(admin.site.urls)),
url(r'^api/login/', obtain_jwt_token),
]

I'm using JWT in a httpOnly cookie and allowing multiple logins on the system. If I have 2 sessions opened with the same user (different JWT tokens) and if one of them logs out I reset all JWT tokens by changing the user's UUID. I also delete that session's cookie by means of:

        response = HttpResponse()
        response.delete_cookie("cookie.jwt",path="/")

This logs out both browser sessions and that's OK, but the browser session in which I DID NOT explicitly log out keeps an invalid cookie in the browser and I can't get rid of it via javascript because its httpOnly (I want it to stay that way). All further requests to the server return as a 401 and I can't seem to change the response to add a "delete_cookie".

Two questions:

1. Why not always delete the cookie JWT_AUTH_COOKIE from the response if an exception is raised by JWT?

2. How can I work around this issue?

Thanks!

I am very confused about using allauth/jwt? I need email verification for account activation/deletion and many other things but i also need jwt token like thing to secure get/post apis.... What can i do???? I am beginner to django....!!!!!!! Sorry if my english is poor....!!!

https://github.com/jpadilla/django-rest-framework-jwt/blob/4021e0bd46eed8ca7dd0ea9337e2606951cb55fb/rest_framework_jwt/serializers.py#L53

When using the default ModelBackend in django settings activated, the authenticate method in django.contrib.auth.backends.ModelBackend has the user_can_authenticate method. In our case user.is_active is False and as a result the whole authenticate method in this file returns None. As a result in line 53 there is a check if the user is_active but it is unreachable in this point and we render the wrong message which is in line 64.

Hello,

I am using email instead of username for authentication. So my custom user model does not have username field. My code is based on this

Now I am setting up jwt authentication and I receive the following warning:

rest_framework_jwt/utils.py:39: DeprecationWarning: The following fields will be removed in the future: `email` and `user_id`.
    DeprecationWarning

Is there something that I can do to overcome this (other than using username, which will not be an option)

thanks!

Hello there,

For a long time now I've honestly thought I'd have the time and energy to come back and work on this project, and I think I still don't. I've not worked on any project recently needing it, which makes it harder to find time to come back.

At some point I also noticed I no longer liked how the project had evolved and that it deserved a fair redesign and there are a few fundamental changes required. Now I'm certain that I wouldn't be able to work on this with the care required for a major version bump.

I'm definitely not proud at how long it has taken me to make this or any update, I recognize that and I'm sorry for not having spoken out sooner.

There's two efforts/projects that I'd like to point out to:

Fork: https://github.com/Styria-Digital/django-rest-framework-jwt Drop-in updated replacement fork. I'm willing to transfer repo, pypi, etc, to keep this going.

Alternative: https://github.com/davesque/django-rest-framework-simplejwt Many of the changes that I've wanted to work on are already done here. This is what I would probably use today.

Learned quite a few things from this. Thanks to everyone, including past collaborators and contributors. ❤️

Update:

I've transferred the repository from @GetBlimp. Neither @GetBlimp nor @gcollazo are involved with this project anymore.

After using JWT token in un unsafe way for a little over an year I've finally decided that I would like to fix my current setup.

I read everywhere that is not good to save a JWT token in the local client and that is best to use Http Only Cookie.

I'm now trying to use JWT_AUTH_COOKIE in order to create an Http Only Cookie. I'm getting the Cookie correctly returned by the server when using getToken API. What I'm wondering now, is how I can refresh the token.

What happens when I call refreshToken I get the following response:

{"token":["This field is required."]}

True, I'm not sending any token in the request's HEADER and that is what I want since the client isn't supposed to keep it saved anywhere.

And that is where I'm getting confused:

If i'm not wrong from now on every request the client does to the server, the cookie should be added to the request.

Shouldn't the server check the cookie after it sees that no token has been passed in the Header?