To whom it may concern,
I hope to get some help urgently on my issue as I have been at it for the last 6-7 days and have came to no working solution. I do ponder is my issue due to Auth0’s end of the code or was it due to the Django’s end of the code.
My original code works perfectly, till I tired implementing JWT Token access to the code base, and everything broke down. My frontend runs on React, while the backend runs on Django.
My intent is to utilize the Machine-to-Machine API Token authentication method, using Client Credentials Flow (Client Credentials Flow). The primary Auth0 backend setup is based from here: Auth0 Django API SDK Quickstarts: Authorization
There will be no-user-login, and only a token authorization will be used.
Presumably, the flow of authentication should be as follows from what I have leant from Auth0’s API:
- Client browser makes Token request from https://.auth0.com/oauth/token endpoint.
- Auth0 authenticates & replies JWT Token.
- Client browser takes received Token & bundles with request to my API server endpoint.
- API Server authenticates Token & processes data from database.
- Client browser received data.
However, at this point, I am faced with a major critical error primarily dealing with 500 error being thrown.
- Once Auth0-JWT Token authentication / Django permissions.IsAuthenticated / Django authentication.JSONWebTokenAuthentication is switched on, only 500 errors are thrown from the server.
I have submitted my Django-end of the code base / issue here: Django REST Framework: Why Adding IsAuthenticated Permissions Only Threw 500 Internal Error Instead of 401 / 403 Errors? - Stack Overflow
I am not sure where I may have done wrong or did I get the Auth0 flow totally wrong. I sincerely hope that someone may assist me, given that this project is delayed and this security segment has sadly gotten it way overdue.
Hope to hear some feedback on this real urgently. Thank you so much!
I immediately confess that I have no hints about the possible reason for the 500 errors, however, there’s a more pressing situation that I think needs to be mentioned so apologies for not answering the exact question you asked.
You mention that there will be no end-user login; however, a browser-based application (React) cannot make use of client credentials. The client credentials grant requires a client application able to perform client authentication which at this time in the Auth0 service is achieved through the means of a client secret.
However, if you include that secret in an application deployed outside a controlled environment, the secret will be available to external parties. In this case is deployed to the browser so it’s available to anyone who can reach the server that serves the application code to the browser.
In conclusion, the current flow is not doing anything because anyone that can access the application can then make calls to the API simply by extracting the client secret from the application. In other words, the token validation process does not seem to be adding any sort of security.
Hi @jmangelo,
Thank you for the swift reply and providing a glimmer of hope where at least there is something new I can look at to resolve the problem.
With regards to your reply on " however, a browser-based application (React) cannot make use of client credentials ", where I generally understood that the method of placing the Client ID + Client Secret on the client browser, even though within a .env file, is not ideal, is there an alternative method by which I may investigate with Auth0?
The only flow that my webapp is functioning on is supposedly “automated”, where only the webapp calls the backend API to access the data, thus I didn’t see the need to setup another database to track the user-logins. Therefore, that was why I found and chose Token authentication as it does seem to fit the purpose.
Given I do acknowledge that my setup is pretty unique and not highly recommended as the frontend is handling the primary functionalities of the authentication as well.
However, as the webapp is a simple idea that I am already at the 99% end, just lacking this API endpoint security segment, I would probably have to minimize any further drastic changes as the project is already overdue for launch.
Thus, based on your professional knowledge and opinion, is there other methods whether I may safely implement these security measures to allow a secured request-reply relationship between React-Django at this juncture? I myself do admit that Django hasn’t always been the easiest for myself to implement checks and debug the potential issues it throws out, notably this constant set of 500 errors.
I have even resorted to changing alternatives JWT API to see whether is there a problem with that, but to no avail.
Hope you can help to give some immediate guidance on this matter. Much appreciated!
Hey @jmangelo,
Just want to provide an update on the matter.
After I went through a granular-attempt to use “print()” to debug potential problem lines of code, I had finally realised the 500 error was due solely on my end. My sincerest apologies for dragging you through this little mess.
The problem ended up was with a line where :
- WORKING — AUTH0_DOMAIN = os.environ.get(‘JWT_AUTH0_DOMAIN’)
- ERROR — AUTH0_DOMAIN = os.environ.get(‘AUTH0_DOMAIN’)
It was probably a serious noob mistake on my part and it was honestly an easy mistake to look over.
The key solution I did was just to add “print(“AUTH0_DOMAIN-----: %r” % AUTH0_DOMAIN)” and realised that the response was “None” instead of a valid url.
Despite resolving this issue, I am still keen to hear other ideas as previously discussed on how to improved my Auth0 flow given that:
- Most processing is handled in the frontend (React).
- Backend still handles database processing at the backend (Django).
- Ideally a Machine-to-Machine Token authentication should be used as no login is setup in the entire system, thus Tokens are a more viable solution to enable API endpoint authentication.
Would love to hear more from you should you have alternatives which I may look at to implement as alternatives, to improve better security while using Auth0.
Thank you so much! Cheers! 
Glad the errors were sorted; the problem with the simple mistakes (in this case a missing prefix in a variable name) is that they are sometimes the harder to find because our human brain just overlooks them. 
In relation to the overall approach I’m afraid that as soon as the client application (the caller of the API) can get deployed to an untrusted environment (in this case the end-user browser) there’s not much to do if you want to ensure that the calls are indeed coming from your application and not just a third-party. At least I’m not aware of any good approach because the easiest is for the caller to know a piece of information (credentials) that the API can validate and trust as only the caller having them.
This works with end-user because they will store that secret (password) in a way that no one else knows it. At least in theory, some end-user choose to store it in post-its and that also does not work.