Django Authentication 6.1

Apply the Django 6.1 prompt first. These additional rules cover Django 6.1.1 authentication on Python 3.12–3.14, using the latest supported Python micro release.

Identity establishment and backend policy

• Treat login() and alogin() as session-establishment APIs: they do not verify credentials, reject inactive users, or enforce MFA. A loaded user object's is_authenticated is always true; it is not proof that the caller authenticated as that user.
• Review AUTHENTICATION_BACKENDS in order: the first successful compatible backend wins. Return None for unverified credentials and raise PermissionDenied for a terminal rejection that must prevent later backends from accepting them.
• Keep any explicit login(..., backend=...) path under server control. Preserve the backend selected by authenticate() rather than letting a request choose which backend will reload its session identity.
• Enforce suspension in custom authenticate() and get_user() implementations and their async counterparts. Default backends reject is_active=False, but models without is_active and the AllowAllUsers*Backend variants remove that protection; AuthenticationForm.confirm_login_allowed() is a separate form-level check.
• When subclassing ModelBackend or RemoteUserBackend, review native async implementations as well as sync overrides. Overriding authenticate(), get_user(), or permission methods alone need not affect aauthenticate(), aget_user(), or async permission checks.
• Use get_user_model() and settings.AUTH_USER_MODEL for identity lookups and