Replace insecure and unmaintained indirect dependencies of `oic` (`pyjwkest`)

[glarrain-cdd]

Expected behavior

All the code used for cryptography, authentication or authorization related operations must be top notch, from popular, maintained and robust libraries.

A popular saying applies: "Good friends don't let friends program cryptography"

Actual behavior

Library oic (OIC = OpenID Connect) uses a crypto-related library that is unmaintained, and has been unable to replace it for over 4 years.

• pyjwkest has a very clear message: "NOTE!! This library is NOT actively maintained anymore." It has not had a release in the last six years.

The ideas of switching to any of these libraries have utterly failed

• pyca/cryptography (the golden standard) has been discussed for over 4 years, without results (GH issue)
• JWCrypto (latchset/jwcrypto) has been discussed for over 4 years, without results (GH issue)

Not crypto-related but with cybersecurity relevance:

• defusedxml (repo): latest release in March 2021

Failure Logs

Check out these alternatives:

• OAuthLib + Django OAuth Toolkit
  • oauthlib): "Python Framework for OAuth1 & OAuth2". "A generic, spec-compliant, thorough implementation of the OAuth request-signing logic for Python 3.6+."
  • django-oauth-toolkit: "Django OAuth Toolkit can help you providing out of the box all the endpoints, data and logic needed to add OAuth2 capabilities to your Django projects. Django OAuth Toolkit makes extensive use of the excellent OAuthLib, so that everything is rfc-compliant."
• Authlib (lepture/authlib): "The ultimate Python library in building OAuth and OpenID Connect servers." Includes integrations with Django, Flask, and other Python web frameworks.

Failure Logs

N/A

Context

N/A

[jbarreau]

Hello @glarrain-cdd, That is a good point we have to change the library we used. But as you may know, the django agent is a v1 style agent, and we have a v2 style currently in beta (for flask only for the moment) that use the same library (oic). After discussion we prefer to use the one in beta state to change the library and back-port to the django agent in a second time.

Thanks a lot for reporting this issue 😄. Best regards.

[glarrain-cdd]

Hello and thanks for your quick response.

But as you may know, the django agent is a v1 style agent, and we have a v2 style currently in beta

I didn't know any of that. I might have missed it in the docs but I think there was no mention of that. There was an option to select Flask in the initial project setup (noting it was beta support) though, but that's it.

If I understand you correctly, the new agent is not only for Flask but also for Django and other frameworks?

Also, what do you mean by "v2 style" and what are the implications of that? Does it mean, for example, that the HTTP API that Forest Admin expect from the Admin Backend is different?

Thanks

[jbarreau]

Hello, There is few reference in the documentation (other documentation/flask) ; it's because it is in beta for now. That I call a "v2 style", is about the conception of the agent, it's design to be easier to use for developers (for example you don't have to define an http route to make a smart action). The design of the v2 agent will permit to support multiple datasource (for example one with django and another one with sqlalchemy), but for now, only sqlalchemy as datasource and flask as web framework are supported (in beta), but django as datasource and web framework are planned. The interactions between forestadmin and the agent stay the same.

Best regards.