django-sesame 3.2.2

Requirements

django-sesame is tested with:

• Django 3.2 (LTS), 4.0, 4.1, 4.2 (LTS), and 5.0;

• Python ≥ 3.8.

It requires django.contrib.auth.

Getting started

Install django-sesame:

$ pip install django-sesame

Open your project settings and add "sesame.backends.ModelBackend" to the AUTHENTICATION_BACKENDS setting. Extending the default value, this looks like:

AUTHENTICATION_BACKENDS = [
    "django.contrib.auth.backends.ModelBackend",
    "sesame.backends.ModelBackend",
]

Now, your project can authenticate users based on django-sesame tokens.

Quick example

Configure LoginView in your URLconf:

from django.urls import path
from sesame.views import LoginView

urlpatterns = [
    ...,
    path("sesame/login/", LoginView.as_view(), name="sesame-login"),
    ...,
]

Load a user from the database:

>>> from django.contrib.auth import get_user_model
>>> User = get_user_model()
>>> user = User.objects.first()

Generate a login URL for this user:

>>> from sesame.utils import get_query_string
>>> LOGIN_URL = "https://127.0.0.1:8000/sesame/login/"
>>> LOGIN_URL + get_query_string(user)
'https://127.0.0.1:8000/sesame/login/?sesame=zxST9d0XT9xgfYLvoa9e2myN'

(Your token will be different from this example.)

Make sure that you’re logged out. Open the login URL. You are logged in!

Use cases

Known use cases for django-sesame include:

1. Login by email, an attractive option on mobile where typing passwords is uncomfortable. This technique is prominently deployed by Slack.

   If you’re doing this, you should define a small SESAME_MAX_AGE, perhaps 10 minutes.

2. Authenticated links. For example, you can generate a report offline and, when it’s ready, email a link to access it. Authenticated links work even if the user isn’t logged in on the device where they’re opening it.

   Likewise, you should configure an appropriate SESAME_MAX_AGE, probably a few days.

   Since emails may be forwarded, authenticated links shouldn’t log the user in. They should only allow access to specific views.

3. Sharing links, which are a variant of authenticated links. When a user shares content with a guest, you may create a phantom account for the guest and generate an authenticated link tied to that account or you may reuse the user’s account.

   Email forwarding is also likely in this context. Make sure that sharing links don’t log the user in.

4. Authentication of WebSocket connections. The web application gets a token generated by the Django server and sends it over the WebSocket connection. The WebSocket server authenticate the connection with the token.

   Here’s an example with the websockets library.

5. Non-critical private websites, for example for a family or club site, where users don’t expect to manage a personal account with a password. Authorized users can bookmark personalized authenticated URLs.

   Here you can rely on the default settings because that’s the original — admittedly, niche — use case for which django-sesame was built.

(In)security

The major security weakness in django-sesame is a direct consequence of the feature it implements: whoever obtains an authentication token is able to authenticate to your website.

URLs end up in countless insecure places: emails, referer headers, proxy logs, browser history, etc. You can’t avoid that. At best you can mitigate it by creating short-lived or single-use tokens.

Otherwise, a reasonable attempt was made to provide a secure solution. Tokens are secured with modern cryptography. There are configurable options for token invalidation.