django-otp
This project makes it easy to add support for one-time passwords (OTPs) to Django. It can be integrated at various levels, depending on how much customization is required. It integrates with django.contrib.auth, although it is not a Django authentication backend. The primary target is developers wishing to incorporate OTPs into their Django projects as a form of two-factor authentication.
Several simple OTP plugins are included and more are available separately. This package also includes an implementation of OATH HOTP and TOTP for convenience, as these are standard OTP algorithms used by multiple plugins.
If you’re looking for a higher-level or more opinionated solution, you might be interested in django-two-factor-auth.
Status
This project is stable and maintained, but is no longer actively used by the author and is not seeing much ongoing investment.
Well-formed issues and pull requests are welcome, but please see CONTRIBUTING.rst first. General questions and ideas should be directed to the Discussions section; issues should be reserved for confirmed bugs.
Development
This project is built and managed with hatch. If you don’t have hatch, I recommend installing it with pipx: pipx install hatch. A justfile is provided with wrappers for scripts in pyproject.toml, so the easiest way to get oriented is to run just.
pyproject.toml defines several useful scripts for development and testing. The default environment includes all dev and test dependencies for quickly running tests. The test environment defines the test matrix for running the full validation suite. Everything is executed in the context of the Django project in test/test_project.
To run the full test matrix, run just test-all. You will need multiple specific Python versions installed for this.
You can clean up the hatch environments with hatch env prune, for example to force dependency updates.
The project under test can be run as a simple interactive test environment: run just runserver and open it in a browser. This has an implementation of the login form and views with different combinations of decorators, which you can experiment with or use to test changes.
Configuration
By default, the test project uses SQLite. Because SQLite doesn’t support row locking, some concurrency tests will be skipped. To test against PostgreSQL, you can add a local configuration file that points to your database.
Configuration is taken from TOML files stored under test/config. A config file named env-<env-name>.toml will be automatically applied when running inside a matching hatch environment. For example, env-default.toml applies to the default development environment and env-test.toml applies to the test matrix environments.
With a wide-open PostgreSQL install, an env-test.toml might look like this:
[database]
ENGINE = "django.db.backends.postgresql"
NAME = "django-otp"
USER = "postgres"For development, the config file can also be used to inject Django apps and middleware, or to override arbitrary Django settings. See test/config/sample.toml for a full description.
You can also force a specific config file by setting the environment variable DJANGO_OTP_CONFIG to a path.
The Future
Once upon a time, everything was usernames and passwords. Or even in the case of other authentication mechanisms, a user was either authenticated or not (anonymous in Django’s terminology). Then there was two-factor authentication, which could simply be an implementation detail in a binary authentication state, but could also imply levels or degrees of authentication.
These days, it’s increasingly common to see sites with more nuanced authentication state. A site might remember who you are forever—so you’re not anonymous—but if you try to do anything private, you have to re-authenticate. You may be able to choose from among all of the authentication mechanisms you have configured, or only from some of them. Specific mechanisms may be required for specific actions, such as using your U2F device to access your U2F settings.
In short, the world seems to be moving beyond the assumptions that originally informed Django’s essential authentication design. If I were still investing in Django generally, I would probably start a new multi-factor authentication project that would reflect these changes. It would incorporate the idea that a user may be authenticated by various combinations of mechanisms at any time and that different combinations may be required to satisfy diverse authorization requirements across the site. It would most likely try to disentangle authentication persistence from sessions, at least to some extent. Many sites would not require all of this flexibility, but it would open up possibilities for better experiences by not asking users for more than we require at any point.
If anyone has a mind to take on a project like this, I’d be happy to offer whatever advice or lessons learned that I can.
1 maintainer
Metadata
1 maintainer
Release files for django-otp 1.7.5
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | |
|---|---|---|---|
| django_otp-1.7.5.tar.gz | 79.6 kB | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| django_otp-1.7.5-py3-none-any.whl | Python 3 | none | any | Details |
Total release size: 153.4 kB
Release files / django_otp-1.7.5.tar.gz
| Download URL | django_otp-1.7.5.tar.gz |
|---|---|
| Size | 79.6 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
7f554d21dcd035550c3b8e3f154b1f422fee71fdc75c8a3bf96e42a2ea6dafcc
|
|
BLAKE2b-256 checksum How to use checksums |
d0e9db4349d7a866e6d5153b31fa740b17f5893723715edf7d1673615d9f462c
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
Hatch/1.16.5 cpython/3.14.7 HTTPX/0.28.1
|
Release files / django_otp-1.7.5-py3-none-any.whl
| Download URL | django_otp-1.7.5-py3-none-any.whl |
|---|---|
| Size | 73.8 kB |
| Tags | Python 3 |
|
SHA-256 checksum How to use checksums |
475d4111e07d61616996f098d08d29884da6397273a11f53c1b8e8c75d27e1dc
|
|
BLAKE2b-256 checksum How to use checksums |
a3bcbda771669006e7e112bed31a330636ff0b3c3407b053c10c492368c35f6f
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
| Uploaded via |
Hatch/1.16.5 cpython/3.14.7 HTTPX/0.28.1
|
