(insecure_transport) OAuth 2 MUST utilize https. about requests-oauthlib

[jtroussard]

This is a security feature and important to the overall viability of an OAuth2 workflow implementation. As you have worked out for yourself the appropriate way to shut the feature off for development purposes would be to set the insecure transport environment variable, beyond that it is not recommended to short-circuit this process.

Using HTTPS when implementing an OAuth2 workflow is cruical to ensure communications between the authorization/authentication/token exchange servers are secure. Of course there are built in features with the codes and tokens themselves however leaking any of this information still presents risk.

I can sympathize with the urge to circumvent this feature when trying to learn by building, however it doesn't consistute a real "issue" and the focus should really be placed on setting up an HTTPS server. While this can seem like an additional task, it is well worth the effort and peace of mind. There are many resources available online to simplify/soften the learning curve. One of my favorites is Let's Encrypt. I encourage you to consider implementing HTTPS instead of undoing a security check. There's a "follow the flow of the river" thing going on here. Moving the application/project to a secured server is the natural flow, while working around the secure server check is swimming against it.

I can imagine this isn't really the feedback you were hoping for, I'm sorry for that believe me, I am. However I hope this answer still helps paint a better/bigger picture and provides some insight on how you can ultimately accomplish your end goal. We can leave this thread open for now if you'd like follow up.

[ssk199441]

Hi @jtroussard

Thank you for your response and for emphasizing the importance of using HTTPS in OAuth2 workflows. I completely agree that maintaining secure communication is crucial, and I appreciate your suggestion to use resources like Let's Encrypt to simplify the process.

To clarify, our server is already configured to use HTTPS, and we understand the risks associated with disabling security features. Our issue arises specifically when using this particular library. Interestingly, when we integrate Authlib for similar workflows, we don't encounter the same problem. This makes me wonder if there's a specific configuration or compatibility issue with the library in question.

To resolve this, we're seeking guidance on how to ensure that our HTTPS setup is correctly recognized and validated by the library. Are there specific settings or parameters that we need to configure to avoid this issue? Alternatively, if there's a known issue or a workaround that doesn't compromise security, that would be extremely helpful.

Your point about not circumventing security checks is well-taken. Our intention is not to bypass these important features but to understand why our current HTTPS configuration is not being acknowledged by the library and how we can correct this. Any insights or resources you could provide on this matter would be greatly appreciated.

We're committed to maintaining a secure and efficient OAuth2 implementation and are keen to resolve this issue in a way that aligns with best practices. Thank you again for your assistance, and I look forward to any further advice you can offer.

[singingwolfboy]

Maybe your server is behind a TLS termination proxy that is not set up in a way that Flask understands? If so, this page might help you out: https://flask.palletsprojects.com/en/3.0.x/deploying/proxy_fix/

EDIT: just noticed that you are using Django Rest Framework, not Flask. Considering that, the link I provided will not help; but maybe the fundamental problem is the same?

[jtroussard]

Is there any more information you can provide to frame your specific situation? logs? server configs? recreation steps?