How to Build Authorization That Actually Works: A Practical Walkthrough

Start With a Number: 12 Hours

NIST SP 800-63B says that at Authenticator Assurance Level 2 (AAL2), authentication must be repeated at least once every 12 hours during an extended session, and after 30 minutes of inactivity. That's not just an authentication rule—it's an authorization rhythm. If your session tokens live forever, your authorization decisions are stale. You're trusting a user's permissions long after their context has changed. This article is for developers, sysadmins, and security leads who need to get authorization right without drowning in theory. I'll walk you through a concrete strategy, step by step.

1. Know Who You're Letting In (Authentication First)

Authorization is meaningless without authentication. You can't decide what someone can do until you know who they are. Tenable lays out the sequence: identification, authentication, then authorization. So before you touch roles or policies, make sure your authentication is solid. Use multi-factor authentication (MFA) for anything sensitive. NIST SP 800-63B defines MFA as requiring two or more distinct factors: something you know, something you have, something you are. For most systems handling personal, financial, or operational data, AAL2 is the baseline. That means MFA with two different factors. If compromise could cause significant harm, go to AAL3: hardware-based authenticator plus phishing resistance.

Don't roll your own password rules. NIST says subscriber-chosen passwords must be at least 8 characters, and you should allow up to 64. Also, check new passwords against a list of known-compromised values and rate-limit failed attempts. These are table stakes.

2. Pick an Authorization Model That Fits Your Org

You have four main models to choose from, each with trade-offs. Cisco Duo summarizes them nicely: DAC is decentralized and flexible, MAC is centralized and restrictive, RBAC scales well for defined job roles, and ABAC is context-aware and granular. Most modern organizations use RBAC as a baseline and layer ABAC on top for context-aware decisions, adding MAC only for classified data. I agree with that approach. Start with RBAC.

RBAC assigns permissions to roles, not individuals. Users inherit permissions by being assigned roles. The ANSI INCITS 359 standard, developed by NIST, defines Core RBAC as the mandatory minimum: user-role and permission-role assignments. That's your foundation. But don't stop there. RBAC alone can't handle dynamic conditions like time of day or device posture. That's where ABAC comes in.

3. Layer ABAC for Context-Aware Decisions

ABAC evaluates attributes of the subject, object, action, and environment—like time or location—to make fine-grained authorization decisions (Cisco Duo). NIST SP 800-162 defines it as evaluating attributes against policies, rules, or relationships to determine allowable operations. In practice, this means you can say things like: 'Allow access only if the user is in the finance role, the request comes from a managed device, and it's during business hours.' That's powerful. But it's also complex. Don't jump to ABAC for everything. Use it where RBAC falls short: for sensitive data, privileged operations, or cross-tenant scenarios.

4. Enforce Least Privilege and Separation of Duties

The principle of least privilege grants users only the minimum access necessary to do their jobs. AWS IAM best practice is to grant least privilege by creating policies that allow only the permissions required for a task. That's not just a nice idea—it's a control. Combine it with separation of duties: divide critical functions among different staff so no single person can commit fraud alone. NIST SP 800-53 lists separation of duties as a security principle. In practice, that means the person who requests a payment isn't the one who approves it. The person who deploys code isn't the one who can alter audit logs.

5. Handle Privileged Access Like a Hazard

Privileged accounts are the keys to the kingdom. NIST PAM guidance notes that their compromise plays a role in many major breaches. You need to treat them differently. Common PAM controls include credential vaulting with password rotation, just-in-time (JIT) privileged access, session recording, and MFA for privileged sessions. Microsoft Entra Privileged Identity Management (PIM) provides time-based and approval-based role activation to mitigate risks of excessive or misused permissions. Use it. Require MFA to activate roles, set start and end dates, and conduct access reviews. If you're on AWS, use IAM roles with temporary credentials instead of long-term keys. AWS IAM roles have no standard long-term credentials; when a user assumes the role, it provides temporary security credentials for the role session.

6. Centralize Policy with Zero Trust Principles

Zero trust moves defenses from static network perimeters to focus on users, assets, and resources (NIST SP 800-207). It grants no implicit trust based on network location. Access is granted per-session, based on dynamic policy considering user, device, and environment state. The architecture relies on a Policy Decision Point (PDP) and a Policy Enforcement Point (PEP). In practice, this means you need a central policy engine. Microsoft Entra Conditional Access is one example: it brings identity-driven signals together to make decisions and enforce policies before granting access. Policies are if-then statements: if a user wants to access Microsoft 365, then they must perform MFA. You can base decisions on user or group membership, IP location, device platform and state, application, and sign-in risk.

If you're building for the U.S. federal government, OMB M-22-09 required agencies to adopt zero trust principles, including phishing-resistant MFA, by the end of fiscal year 2024. Even if you're not federal, that's a good target.

7. What Can Go Wrong: The Token That Never Expires

Here's a real scenario: You implement OAuth 2.0 for a third-party app. You use the authorization code grant, but you skip PKCE because it's a confidential client. Then you issue access tokens with a 24-hour lifetime and no refresh token rotation. An attacker steals a token via a compromised log. They now have 24 hours of access. Because you didn't implement token revocation or short expiration, you can't stop them. This is why NIST SP 800-63B requires reauthentication every 12 hours at AAL2. Your authorization tokens should be short-lived, and you should validate them on every request. Use PKCE (RFC 7636) for public clients. Use bearer tokens carefully—RFC 6750 defines them as tokens where any party in possession can use them. That means if they leak, game over.

Comparison: Choosing Your Authorization Model

Quick tip: Start with RBAC as your baseline. Add ABAC for the 10% of decisions that need context. Don't try to boil the ocean.

Your Action Plan

Here's what to do next:

• Audit your current authentication: is MFA enforced? Are sessions limited to 12 hours?
• Define roles based on job functions, not individuals. Implement Core RBAC.
• Identify three high-risk scenarios where context matters (e.g., off-hours access, unmanaged devices) and pilot ABAC there.
• Implement PAM for privileged accounts: vault credentials, require JIT access, record sessions.
• Adopt a zero trust policy engine like Conditional Access if you're in Microsoft, or build a PDP/PEP model if you're not.

Authorization isn't a one-time setup. It's a continuous process. Review roles quarterly, rotate credentials, and monitor for anomalies. If you do that, you'll sleep better at night.

Sources

• Tenable - https://www.tenable.com/cybersecurity-guide/learn/key-iam-components
• Cisco Duo - https://duo.com/learn/access-control-models
• NIST SP 800-63B - https://pages.nist.gov/800-63-3/sp800-63b.html
• NIST PAM - https://www.nccoe.nist.gov/financial-services/privileged-account-management
• Microsoft Entra Conditional Access - https://learn.microsoft.com/en-us/entra/identity/conditional-access/overview
• OMB M-22-09 - https://www.whitehouse.gov/wp-content/uploads/2022/01/M-22-09.pdf