Anyone figure out how to use Auth0 with Django Rest Framework SimpleJWT (GitHub - jazzband/djangorestframework-simplejwt: A JSON Web Token authentication plugin for the Django REST Framework.)? The User Guide refers to djangorestframework-jwt which is deprecated.
I am not familiar with simple jwt, but I may be able to help. What are you trying to accomplish?
@dan.woda I’m trying to get Django Rest Framework working with Auth0 
TL;DR; how can I get DRF to accept an access_token from Auth0 using the simpleJWT library?
So the user guide and all existing examples on using Auth0 with DRF refer to the djangorestframework-jwt package, which is now deprecated (see here: Status · Issue #484 · jpadilla/django-rest-framework-jwt · GitHub) Looking to the future, jpadilla recommends simplejwt, which is the package I linked above. However, it’s not clear how to set the environment variables in order for this package to work.
For instance, the user guide says to set the ‘audience’ parameter to the Auth0 Client ID, as opposed to the Audience; and this is just one idiom out of what is undoubtedly many…
And you looked at our quickstart?
(reposting since apparently the reply via email doesn’t post here)
I did look at the quickstart. The issue is that I’m wanting to use a different JWT library than the one listed in the Quickstart.
I’ve uploaded a test repo that demonstrates what I’m trying to accomplish. I think the answer is to be found in the settings here: https://github.com/dbinetti/tutorial/blob/master/tutorial/settings.py#L33
There is a docstring underneath the settings themselves that describe what each of the settings mean to SimpleJWT – getting the answer to those settings is likely the solution.
1 Like
Okay I took a look at it.
Signing Key is going to depend on the algorithm.
We recommend you use RSA256 for the signing algorithm, which should eliminate the need for a signing secret unless you are generating tokens. I’m not sure how simple JWT is going to treat this, so you may need a signing key. I am a bit unsure here tbh.
The public key or Verifying Key (if you choose RSA256) can be found at a discovery endpoint; more on that here.
If you choose to go with HSA256, you will need to ensure that your api is registered as such when you create it in the dashboard, then the signing key will be listed below your chosen algorithm. No verifying key necessary.
Issuer is usually your auth0 domain. e.g. https://{AUTH0_DOMAIN}/
Audience is the consumer of the token, typically a uri of some kind. It is usually the whatever you register the API as in the auth0 dashboard. If you navigate to your api it would be marked as the identifier.
I can’t speak to JTI_Claim. That may require more research but shouldn’t be necessary.
With all that being said, it will be a bit simpler to go with the recommended library from the quickstart, and should have the same end result, but cheers to learning new libraries! 
Let me know if that helps!
Thanks,
Dan
Fair enough. But my reason for wanting to make the switch is that:
- the Quickstart’s library was forked from a deprecated project that hasn’t changed much since the fork.
- the original author himself said that were he to make a choice it would be for SimpleJWT and not the fork, and
- SimpleJWT has 1,200 stars v. 30 for the fork – so there is a very clear preference.
SimpleJWT didn’t exist when the Quickstart was authored, so perhaps what really is needed here is an updated Quickstart? Again, not trying to be a PINA, but if the author himself is suggesting the alternative as the way forward then I’m going to listen pretty closely to that.
Anyway, I understand if this is beyond the scope of what’s possible. It’s just a bit disheartening.
Thanks
3 Likes
That seems plenty legitimate.
This is possible, and we appreciate the feedback. I am going to pass the idea along to the team who manages the quickstarts and sdks.
Thanks,
Dan
One more update.
I talked to Jose, the original author of the django rest framework jwt library a bit about this. It seems that there is internal discussion about the topic already. I have no timelines or anything, but the teams know about these external libraries and are working on it.
That’s very good to hear! Thank you; I look forward to hearing what happens from these discussions.
1 Like
Hey guys, I don’t want to break any community guidelines by me-tooing but I just wanted to point out that I’m having the exact same problem and I’m currently using the poorly maintained fork that @dbinetti has mentionned, and would also like to switch to the 1.2k-starred simplejwt.
I’ve tried a lot of things, but I believe simplejwt is more oriented towards generating tokens and signing them than interacting with an external provider. No custom handler is provided, the settings are quite static.
@dan.woda : Any ETA on an updated quickstart? I could use a guiding hand through this.Thanks a bunch !
1 Like
Quick update, I’ve managed to make it work by subclassing the Token class in rest_framework_simplejwt.tokens.
Basically, I’ve replaced self.payload = token_backend.decode(token, verify=verify) in the constructor by my own decoding backend using jwt (also what is recommended in Auth0’s Django API quickstart).
Instead of getting the verifying key (which is basically the public_key in the quickstart) from a static settings.py variable (in SIMPLE_JWT), I’m retrieving it from an Auth0 endpoint.
4 Likes
Thanks for showing us how you worked it out!
No ETA at this time unfortunately, but this is not lost.
Thanks,
Dan
1 Like
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.