Can Django REST Framework authentication classes fall back after an expired credential raises AuthenticationFailed?

Designing fallback authentication for expired credentials

When a Django REST Framework view lists multiple authentication classes, the first class that returns a user object sets request.user, while any class that raises AuthenticationFailed immediately stops evaluation. In a least-privilege design, an expired Basic credential or revoked token in an earlier class currently prevents later classes from being tried, because BasicAuthentication and TokenAuthentication raise exceptions rather than returning None. SessionAuthentication behaves differently by returning None when no session user exists, allowing the chain to continue.

Because the core rest_framework.authtoken package has no built-in expiration field, projects must decide how to represent expired credentials and whether to catch backend failures in custom classes. Swallowing exceptions entirely may mask security issues, so the tradeoff between fallback availability and auditability remains unresolved.

Does the sequential evaluation model in DRF 3.x permit a built-in or custom authentication class to return None after an expired credential is detected, allowing a subsequent class to run? What is the recommended pattern for enforcing token expiration without modifying the core authtoken model? How should failures be logged when a custom class intentionally declines to authenticate?