juanifioren / django-oidc-provider

OpenID Connect and OAuth2 provider implementation for Djangonauts.
http://django-oidc-provider.readthedocs.org
MIT License
423 stars 238 forks source link

Performance problems with /token endpoint #374

Open troeger opened 4 years ago

troeger commented 4 years ago

We are running a Django application with the library on a 5 years old machine:

Prozessor: Opteron 6378 (1.3 GHz) Python: 3.6 Django: 2.2.16 django-oidc-provider: 0.7.0

We got reports about extremely slow OAuth login flows against our code. A python profiling run showed that Cryptodome seems to take a lot of time for the token generation:

image

I could not find any note or issue at the Cryptodome project about this. The same holds for the django-oidc-provider project. Is this normal and expected? Should that be treated as a problem of our hardware?

geoff-va commented 2 years ago

I've seen a similar issue and I tracked it down to how keys are loaded.

https://github.com/juanifioren/django-oidc-provider/blob/master/oidc_provider/lib/utils/token.py#L159

If you trace this back into the importKey function, it's actually running all the consistency tests to ensure this is a valid private key. There is a lot of CPU involved in the various primality tests and such. So each time this is called it's running those tests against every private key on the system, which can lead to a heavy load. Same can go for the jwks endpoint.

Since these are private keys that we generated, I don't believe it should be necessary to perform these checks every time we load one of our own private keys. Those consistency checks were done when the key was generated.

importKey ultimately leads here, where there is a call to construct which has consistency_check=True as the default.

This is sped up dramatically if you load the key without the consistency check.