Use the identity layer for authentication and the application for enforcing its own route and role decisions unless the architecture clearly centralises both. The important thing is consistency: the app must consume one authoritative role source and apply it to privileged paths in the same way every time.
Where Django Should Enforce Authorisation, and Where It Should Not
Authorisation inside Django should be treated as the application’s enforcement layer, not a replacement for the identity layer. The identity layer should establish who the user is and issue trusted claims; Django should consume those claims and make the route, object, and role checks that are specific to the application. That separation keeps responsibility clear and avoids duplicating policy logic in two places.
When teams blur that boundary, the common failure is inconsistent policy. One endpoint checks a role one way, another endpoint checks it differently, and privileged paths drift over time. If the architecture centralises both authentication and authorisation, that can work, but only when the application still consumes one authoritative source of truth and applies it consistently.
For a practical view of role and policy design, Authorisation Models Guide is useful because it frames RBAC, ABAC, ReBAC and externalised policy decisions as design choices rather than assumptions. If your Django app is enforcing its own decisions, the role model still needs to be explicit, stable, and understandable to the teams maintaining the routes.
How to Split Responsibilities Without Creating Policy Drift
The clean split is simple: let the identity layer authenticate, then let Django authorise against the claims or role data it receives. That can be session claims, JWT claims, a policy decision service, or a local permission table, but the key point is that Django should not invent a second, competing source of truth for the same privilege decision.
Where teams run into trouble is mixing coarse identity data with business-specific access rules. The identity layer may know that a person belongs to a group, but Django often needs a more specific rule, such as whether that group may access a particular workflow, tenant, or object. The application therefore owns route and object enforcement, while the identity layer supplies the authoritative identity context.
If the system includes broader IAM and governance concerns, IAM and IGA Basics helps anchor the split between authentication, entitlement governance, and application access management. For teams deciding where roles should live, the rule of thumb is to keep the identity layer authoritative for identities and entitlements, then let Django apply the application-specific decision on top.
What Good Looks Like in Django Authorisation Design
Good design means every privileged path is checked in the same way, using the same authoritative role source, with no bypass for “temporary” views, admin shortcuts, or one-off scripts. In Django that usually means permission checks are close to the view or policy boundary, and the app treats missing or stale claims as a denial rather than guessing.
It also means the role model is stable enough to audit. If developers have to interpret business meaning from ad hoc flags in code, the access model is already too loose. A well-run application will document which claims it trusts, which roles it maps, and which operations require a fresh decision versus a cached one.
When teams need a lifecycle view of those privileges, NHI Lifecycle Management Guide and Role Mining and Role Design Guide are helpful complements because they show why roles and access paths must be owned, reviewed, and kept from expanding silently. Even in a Django-centric pattern, the same discipline applies: role meaning must stay current, or the application becomes a place where privilege creep accumulates unnoticed.
Risk and Threat Considerations
When authorisation logic is split badly, the risk is not just a bug, it is uneven access enforcement across routes, object views, and admin functions. Attackers and internal misuse alike benefit from inconsistencies because the weakest endpoint becomes the easiest way to bypass intended policy.
Failure mechanism: The application trusts stale, ambiguous, or duplicated role logic, or it implements policy differently in separate code paths, creating privilege gaps that are hard to spot in review and easy to miss in testing.
Impact: Users may gain access to data, actions, or admin functions they should not reach, and the organisation may lose confidence that privilege decisions are being enforced consistently.
For teams that expose APIs or admin surfaces alongside Django views, Privileged Access Management Guide is a useful companion because privileged routes need the same careful treatment as elevated sessions and break-glass access. In practice, inconsistent route checks are often less about one broken control and more about many small exceptions that add up to an exploitable path.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | Django must enforce route and object access decisions consistently. |
| IA-2 — Identification and Authentication (Organizational Users) | The identity layer establishes the user's authenticated identity before authorisation decisions. | |
| IA-5 — Authenticator Management | Authoritative identity claims depend on sound credential and session handling. | |
| Recommendation — Implement AC-3 so every privileged Django path evaluates access before execution. Use IA-2 to establish trusted user identity before application authorisation. Apply IA-5 to govern credential and token handling that feeds application claims. | ||
| OWASP ASVS | V8 — Authorization | ASVS directly addresses application authorization checks and enforcement consistency. |
| V10 — OAuth and OIDC | Identity-layer authentication commonly relies on OAuth and OIDC in this split-design pattern. | |
| Recommendation — Use V8 to verify every protected Django function enforces authorisation consistently. Apply V10 to validate trusted identity claims before Django consumes them. | ||
Practitioner Guidance
What to verify: Confirm there is exactly one authoritative role source for the application, and verify that every privileged route, object lookup, and admin action consumes it through the same code path or policy interface. If developers are re-deriving privileges inside views, that is a sign the design needs consolidation.
Decision rule: If the identity layer already expresses the role or entitlement accurately, let Django enforce it consistently rather than rebuilding role logic in multiple services. If the application needs business-specific rules that the identity layer cannot express cleanly, keep the identity source authoritative and add the app-specific check as a second, explicit enforcement step.
Common mistake: Treating authentication, group membership, and authorisation as interchangeable. They are not, and collapsing them leads to brittle code, unclear ownership, and access decisions that are hard to audit.
Practitioner takeaway: The safest pattern is not “identity or Django”, it is “identity for trusted claims, Django for consistent enforcement”, with one authoritative role source and no duplicate policy interpretation.
Related resources from NHI Mgmt Group
- Why do teams often misapply identity tools when the real gap is application authorization?
- What breaks when teams only monitor access at the file layer and ignore identity-wide authorization sprawl?
- How should teams design application authorization when different users need different actions inside the same private network app?
- How should security teams decide whether to build authorization logic inside applications or externalize it to a centralized policy layer?