Splitting Django authentication between public and internal interfaces

By

Intro

Probably the most used Django feature is the admin. It’s rated as the most useful feature according to the Annual Django Survey. It helps to bring content management up to speed and with some love and effort, we can build rich management platforms with it.

The challenge

Django admin has a single users table, single session management and a single set of roles (users, groups, permissions). Public facing apps often leave the /admin available to the world. This is still bearable, but it brings some overhead to assuring the authorization is done right. Of course, MFA helps a bit, but that’s not a silver bullet.

Some best practices recommend splitting the authentication between public and internal systems. Some companies may have policies requiring this separation, and there are cases where it makes sense to completely separate the public part of application from the internal one. Including user management and authorization. Good example are ecommerce platforms where minimizing risk of any accidental opportunity for the user to have their permissions elevated is very welcome.

Preparing the project

In many cases, we would just rely on is_superuser or is_staff to take care of accessing Django admin. But for this case, we will approach it like two different applications. One will be public and the other one will provide Django admin, an internal interface. We will use the same project, just with two deployments and configurations.

Setting up the project

cd ~/our/project_root

poetry init
poetry add Django
poetry run django-admin startproject split

cd split

poetry run ./manage.py startapp account

Preparing the settings

We need to edit the settings.py by placing a line somewhere on top (we can do it just after the imports)

ENVIRONMENT = os.getenv('ENVIRONMENT', 'public')

This will be used in the next step to define which configuration to use.

Next, we modify INSTALLED_APPS:

INSTALLED_APPS = [
    # 'django.contrib.admin',
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    'account',
]

Commenting out admin and adding the account one. Note the admin doesn’t have to be commented out, but there is no reason for it to be loaded in the public environment.

Adding account models

Next we need to add models into account app:

from django.contrib.auth.models import AbstractBaseUser, BaseUserManager
from django.contrib.sessions.models import AbstractBaseSession, BaseSessionManager
from django.db import models
from django.utils import timezone


class SessionManager(BaseSessionManager):
    use_in_migrations = True


class PublicSession(AbstractBaseSession):

    class Meta(AbstractBaseSession.Meta):

        db_table = "django_session_public"
    
    objects = SessionManager()

    @classmethod
    def get_session_store_class(cls):
        from .session import SessionStore
        return SessionStore


class UserManager(BaseUserManager):
    """Define a model manager for User model with no username field."""

    use_in_migrations = True

    def _create_user(self, email, password, **extra_fields):
        """Create and save a new user with the given email and password."""
        if not email:
            raise ValueError('Email is required')
        email = self.normalize_email(email)
        user = self.model(email=email, **extra_fields)
        user.set_password(password)
        user.save(using=self._db)
        return user

    def create_user(self, email, password=None, **extra_fields):
        """Create and save a regular User instance with the given email and password."""
        return self._create_user(email, password, **extra_fields)


class User(AbstractBaseUser):

    USERNAME_FIELD = 'email'
    REQUIRED_FIELDS = []
    email = models.EmailField('Email Address', unique=True)
    first_name = models.CharField(max_length=255, blank=True)
    last_name = models.CharField(max_length=255, blank=True)
    is_staff = models.BooleanField(default=False)
    is_active = models.BooleanField(default=False)
    is_superuser = models.BooleanField(default=False)
    date_joined = models.DateTimeField(default=timezone.now)
    date_activated = models.DateTimeField(null=True, blank=True)

    objects = UserManager()

    def __str__(self):
        return self.email

Extending the settings

And then we add more settings to the end of settings.py:

if ENVIRONMENT == 'admin':
    SECRET_KEY = 'f)@*$1$t(r(4@zzx14-$nf-g!9_(f)4y5(0ptl&77==tuv@1q0'
    INSTALLED_APPS.append('django.contrib.admin')
elif ENVIRONMENT == 'public':
    SECRET_KEY = '-cme0m8%$s32=xmo60k(l+mmhsln7wl!&l=6or3bgu^dw#86h2'
    AUTH_USER_MODEL = 'account.User'
    AUTHENTICATION_BACKENDS = ['account.backends.EmailBackend']
    SESSION_ENGINE = "account.session"
    SESSION_COOKIE_NAME = "sessionid_public"
else:
    raise ValueError(f'Invalid environment: {ENVIRONMENT}')

The first condition loading django.contrib.admin for the admin environment. The second one is for the public environment. If the condition is met, we load the custom auth model, custom email backend and custom session engine with dedicated table.

Adding the custom session engine

The session engine is a very simple override:

from django.contrib.sessions.backends.db import SessionStore as DBStore
from .models import PublicSession


class SessionStore(DBStore):

    @classmethod
    def get_model_class(cls):
        return PublicSession

Email back end

This will make the email authentication work with the custom setup:

from typing import Optional
from django.contrib.auth import get_user_model
from django.contrib.auth.backends import ModelBackend


class EmailBackend(ModelBackend):

    def authenticate(self, request, username: Optional[str] = None, password: Optional[str] = None, **kwargs):
        if not username or not password:
            return None
        UserModel = get_user_model()
        try:
            user = UserModel.objects.get(email=username)
        except UserModel.DoesNotExist:
            return None
        if user.check_password(password) and self.user_can_authenticate(user):
            return user
        return None

Migrations

First we will run the admin migrations (this will be run only once):

ENVIRONMENT=admin poetry run ./manage.py migrate

ENVIRONMENT=public poetry run ./manage.py makemigrations account
ENVIRONMENT=public poetry run ./manage.py migrate

The above migrates both the auth and account models.

Adding template and views

We edit the account/views.py file adding the following:

from django.contrib.auth import login, logout
from django.contrib.auth.forms import AuthenticationForm
from django.shortcuts import redirect, render


def demo_view(request):
    if request.method == 'POST':
        form = AuthenticationForm(request, data=request.POST)
        if form.is_valid():
            login(request, form.get_user())
            return redirect('demo_view')
    else:
        form = AuthenticationForm() if not request.user.is_authenticated else None
    context = {'form': form}
    return render(request, 'account/demo.html', context)


def logout_view(request):
    logout(request)
    return redirect('demo_view')

For demo purposes, we only add demo view which will also serve as a login page and logout view. On POST request we try to login the user with provided credentials. Otherwise we either display login form or no. The rest is processed in the following account/templates/account/demo.html template file:

{% block content %}
  {% if user.is_authenticated %}
      <p>Logged in as {{ user }}</p>
      <form method="post" action="{% url 'logout_view' %}">
          {% csrf_token %}
          <button type="submit">Logout</button>
      </form>
  {% else %}
      <form method="post">
          {% csrf_token %}
          {{ form.as_p }}
          <button type="submit">Login</button>
      </form>
  {% endif %}
{% endblock %}

Finally the split/urls.py file:

from django.contrib import admin
from django.urls import path
from django.conf import settings

from account.views import demo_view, logout_view

urlpatterns = []

if settings.ENVIRONMENT == 'admin':
    urlpatterns.append(path('admin/', admin.site.urls))
else:
    urlpatterns.append(path('', demo_view, name='demo_view'))
    urlpatterns.append(path('logout/', logout_view, name='logout_view'))

Testing the setup

Admin instance

Let’s create superuser account:

ENVIRONMENT=admin poetry run ./manage.py createsuperuser
Username: super
Email address: super@super.sup
Password: 
Password (again): 
Superuser created successfully.

We can now start the admin instance:

ENVIRONMENT=admin poetry run ./manage.py runserver 0.0.0.0:8880
Watching for file changes with StatReloader
Performing system checks...

System check identified no issues (0 silenced).
February 25, 2025 - 20:23:42
Django version 5.1.6, using settings 'split.settings'
Starting development server at http://0.0.0.0:8880/
Quit the server with CONTROL-C.

After opening http://localhost:8880/admin we should see the login form. We can login with user super and the password we set.

Logged in as super

But we don’t have a way to add the public facing user, do we? Let’s extend the account app with in account/admin.py file:

from django.contrib import admin
from django.contrib.auth.admin import UserAdmin
from django.contrib.auth.forms import UserCreationForm, UserChangeForm

from .models import User


class AccountUserAdmin(UserAdmin):

    form = UserChangeForm
    add_form = UserCreationForm

    list_display = (
        'email', 'first_name', 'last_name', 'is_active', 'last_login')
    list_filter = ('is_active', 'date_joined', 'date_activated', 'last_login')
    fieldsets = (
        (None, {'fields': ('email', 'password')}),
        ('Personal info', {'fields': ('first_name', 'last_name')}),
        ('Important dates', {'fields': ('last_login', 'date_joined', 'date_activated')}),
        ('Permissions', {'fields': ('is_active',)}),
    )
    add_fieldsets = (
        (None, {
            'classes': ('wide',),
            'fields': ('email', 'first_name', 'last_name', 'password1', 'password2', 'is_active'),
        }),
    )
    search_fields = ('email', 'first_name', 'last_name')
    ordering = ('email',)
    filter_horizontal = ()

admin.site.register(User, AccountUserAdmin)

After the dev server reloads and we refresh the admin site, we should see the new app with Users.

Users in admin

And we add a new user:

Add user

Once it is done, we can proceed.

Public instance

We start the public instance:

ENVIRONMENT=public poetry run ./manage.py runserver 0.0.0.0:8881
Watching for file changes with StatReloader
Performing system checks...

System check identified no issues (0 silenced).
February 25, 2025 - 20:38:09
Django version 5.1.6, using settings 'split.settings'
Starting development server at http://0.0.0.0:8881/
Quit the server with CONTROL-C.

And we check http://localhost:8881/. We should see the login form

Login form

And then:

Logged in as user

Limitations / Constraints / Considerations

We can check that we have two sets of session keys

Session keys

This name differentiation is not required because the two interfaces will sit on two different subdomains/domains/whatever. It is for demo purposes and in this demo case it helps us to be logged in as both users in both urls on localhost within the same browser. What won’t work however is the csrf token. It will work in two browsers or in two subdomains/domains though (or you will have to remember refresh the other tab after you’ve done something in the first one).

In the PublicSession we inherit from AbstractBaseSession and not from Session (what would be easier). This we do to really split auth completely. If we inherited from Session the approach would still work, but the new table would only reference the primary django_session and that would mean the session ids would be stored in the table used for admin interface. In such a case if we had two users (one admin one public) with the same user id and if we used single SECRET_KEY, the session store would be then possibly pointing to an id of super user. The overall risk would be close to zero, but let’s rather have it this way. Anyways, having two SECRET_KEY values means, if we attempted cross-access between session keys, we would receive Session data corrupted error.

There could be some corner cases where the SessionStore is imported from django.contrib.sessions.backends.db and not account.session. This shouldn’t be a problem for most cases. But in case we plan to work with the direct imports somewhere, we have to take this into account.

Outro

This is one of the options how to approach complete separation of users between the internal management and public facing app. One of the limitations of this approach is that we completely skipped groups and permissions. In case you want to use the built-in RBAC, this solution won’t work for you as is.

Please take this as a part of puzzle which you can build on top of. But you still need to approach it with caution as any work related to authentication and authorization.

You can find the complete example in Github

Tags