Asynchronous Support in Django Authentication

Your plan to make Django's authentication system fully asynchronous is well-aligned with Django's ongoing evolution toward better async support. Based on the information from Django's documentation and codebase, here's my analysis of your proposal:

Current State of Async in Django

Django 3.1 introduced support for asynchronous views and middleware, allowing developers to use async def for view functions:

PYTHONCopied
async def my_view(request):
    await asyncio.sleep(0.5)
    return HttpResponse("Hello, async world!")

However, as noted in the documentation, Django's ORM, cache layer, and other components that perform long-running network operations don't yet fully support async access. This is where your proposal comes in.

Analysis of Your Proposal

1. Adding Async Interface to Auth API

This is a logical first step. Looking at the test file test_async_auth.py, it appears Django already has some async authentication functions like aauthenticate, alogin, alogout, and aget_user. Your proposal to expand this interface is consistent with Django's direction.

2. Asyncify Signals

This is indeed necessary for fully async auth. Signals are used extensively in the auth system for actions like pre-save and post-save hooks.

3. Asyncify Sessions

Sessions are critical for authentication, so this step makes sense. Without async sessions, you'd have context switches when accessing session data.

4. Asyncify Auth Backends/Internals

The documentation mentions that authentication backends can implement async versions of functions like aget_user and aauthenticate. When these aren't provided, Django uses sync_to_async to create them automatically, but with performance penalties.

From Django 5.2 documentation:

To optimize performance when called from an async context authentication, backends can implement async versions of each function - `aget_user(user_id)` and `aauthenticate(request, **credentials)`.

5 & 6. Resolve Ticket 31920 and Asyncify Auth Middleware

These steps are necessary to complete the async request path. The AuthenticationMiddleware is a key component that would benefit from being fully async-native.

Addressing Your Open Questions

A. Async-Compatible Decorators

This is related but could be handled separately. Many auth decorators like @login_required would need async versions.

B. Reducing Code Duplication

This is a challenge. Some approaches:

1. Base Implementation + Wrappers: Have one implementation (either sync or async) and wrap it for the other context.

2. Shared Core Logic: Extract core logic into helper functions that both sync and async versions call.

3. Code Generation: Though not ideal, you could use templates or code generation to maintain both versions.

C. Potential Pitfalls

1. Testing Complexity: Testing both sync and async paths thoroughly will be challenging.

2. Backward Compatibility: Ensuring existing code continues to work is critical.

3. Performance Monitoring: Need to ensure async versions actually perform better in real-world scenarios.

4. Database Transactions: Handling transactions in async contexts can be tricky.

Conclusion

Your approach is sound and aligns with Django's direction. The biggest challenges will likely be:

1. Coordinating with other async efforts in Django (signals, sessions)
2. Maintaining both sync and async interfaces without duplication
3. Ensuring backward compatibility

The test file test_async_auth.py shows that some of this work has already begun, which is encouraging. Your proof-of-concept implementation will be valuable for demonstrating the full vision.