Should I use JWT or Basic Token authentication in Django Rest Framework?

Question

I'm about to implement Token Authentication in my API using Django Rest Framework. But I'm not sure if I should use the basic token build-in DRF or use the JSON Web Token (JWT) standard (using this package djangorestframework-jwt) The only reference that I found was in the DRF docs:

Unlike the built-in TokenAuthentication scheme, JWT Authentication doesn't need to use a database to validate a token.

Is there any other difference, advantages or disadvantages to consider?

Note: The API is gonna be accessed from the website (using angularjs) and by a mobile app

Literal

Answer 1

There are many benefits to using JWT tokens regardless of the platform. JWT tokens base64 encode all the users claims in their body and can be safely decoded on the client into a stateful object. This is hugely beneficial when compared to alternative opaque tokens which provide zero use to the client app. On login, you immediately have atomic data in the client without additional round trips to the API to poll for user information.

JWT tokens are stateless: there is no need to store or keep track of them server side, which is more scalable horizontally across many servers. They are safe because the private signing key used to grant them is stored server side, any inbound API calls bearing them are simply validated with the private key, guaranteeing they were issued by your Authorization API.

JWT tokens work nicely in Angular, React, and any other client framework. Because they are JSON, you can base64 decode them in the client and bind client UI elements directly to your claims - someone with an admin claim can see an admin menu and a user without that claim will never know the menu exists, if implemented correctly.

Aside from this, a JWT token still behaves in the same way as any bearer token:

• Issued by Authorization API
• Stored by client in cookies or local storage
• Passed to Resource API in Authorization header

In summary, you will have fewer N+1 trips back and forth between your client and server as well as less work to scale if you implement JWT tokens.

Rideout

There are a couple of downsides to consider: 1) the size of the JWT can increase the bandwidth usage in some instances, especially if you encode more data in the JWT. 2) additional CPU time will be required on the server side if you need to verify and decode the incoming JWT request... – Hyperplane

1) True. Claims encoded in the token should definitely be weighed here and kept minimal per your needs. It's usually the case that additional round trips would be required to pull the claims data if you do not encode in the token and network trips are much more expensive / not atomic. JWT wins here in most cases (IMO). 2) CPU time on the server for this is much less expensive / complex than the alternative of looking up the session from a shared database. JWT allows each server node to verify independently and therefore can be scaled horizontally. – Rideout

would the best library to implement jwt in django be django-rest-framework-simplejwt (github.com/jazzband/django-rest-framework-simplejwt) instead of djangorestframework-jwt (github.com/jpadilla/django-rest-framework-jwt) since the latter is now unmainted? – Goins

Answer 2

JWT:

1. Any client that has it can ask for stuff (similar to money when buying stuff)
2. No database lookup once issued - embedded expiry dictates validation

JWT has an expiry date and until that time, it will remain valid. This may be undesirable when you need to log out a user on password reset, or forced.

A token blacklist may be used to address the above issues. This will re-introduce persistent or in-memory tracking which JWT was trying to avoid in the first place. However, the tracking will be on selected keys ONLY, whereas, the Basic Token Auth, the tracking is for all users.

JWT can be decoded by anyone who has it. Therefore one needs to be mindful of the information packed in the token. The Basic Auth Token, on the other hand, is just a simple hash, which can be seen as just a reference to a user.

With caching and other performance enhancements in mind, one may not need to worry about the overhead, but the convenience and the future proofing of the flow.

Having full control over authentication, authorization and invalidation is a good thing to have, no matter whether JWT + blacklist or Basic Token Auth is used.

Therefore, the Basic Auth Token may be better if the flow is customized to address the needs.

Ralfston