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
Answers:
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.
JWT:
Any client that has it can ask for stuff (similar to money when buying stuff)- 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.
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
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
Authorizationheader
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.
JWT:
Anyclient that has it can ask for stuff (similar to money when buying stuff)- 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.