Django Authentication 5.2

Apply the Django 5.2 prompt and its Python baseline first. Use these rules for Django 5.2 authentication code through 5.2.17, on a maintained Python 3.10–3.14 micro release; Python 3.14 requires Django 5.2.8 or later. Keep deployments on the latest supported 5.2.x patch.

Authentication backends and entry points

• In async views, await aauthenticate(), alogin(), alogout(), request.auser(), and asynchronous permission checks such as user.ahas_perm(); never authorize from the truthiness of an unawaited coroutine.
• Treat login() and alogin() as session establishment, not credential or account-policy verification. Pass an explicitly authenticated user; select any explicit backend argument from trusted server configuration, never request data.
• Enforce account disablement in custom get_user() and aget_user() as well as authentication: existing sessions reload through these methods without repeating credential checks. ModelBackend.user_can_authenticate() allows a user with no is_active attribute, and AbstractBaseUser.is_active alone is a constant True.
• Check policy parity when subclassing ModelBackend or RemoteUserBackend: their native async methods need not call overridden synchronous authenticate(), get_user(), or permission methods. Keep compatible credential signatures; even aauthenticate() selects backends using the synchronous authenticate() signature.
• Do not rely on AuthenticationForm.confirm_login_allowed() outside that form. login_required and LoginRequiredMiddleware do not independently reject inactive users; keep