Fine-Grained Authorization

Definition

Think about how security works in a hospital. It’s not just “doctors can enter the building and patients can’t.” A cardiologist can see heart-related records but not psychiatric notes. A nurse can view vital signs but not billing information. A patient can see their own complete file but nothing about other patients. The administrator can see everyone’s demographic data but not medical details. A visiting specialist can view one specific patient’s file for one day only. This nuanced, context-aware, field-level access control is fine-grained authorization - and modern applications increasingly need this level of sophistication.

Fine-grained authorization goes beyond simple “can this user access this resource?” questions to ask much more specific ones: “Can this specific user perform this specific action on this specific field of this specific record at this specific time from this specific location?” Instead of binary yes/no access to an entire database table, fine-grained authorization controls access at the row level (you can only see your own orders), the column level (you can see the customer name but not their SSN), the operation level (you can view but not delete), and even based on environmental conditions (only from the office network, only during business hours).

This level of control is essential in industries with complex regulatory requirements - healthcare (HIPAA), finance (SOX, PCI), and government (FedRAMP). But it’s increasingly common in consumer applications too. Google Docs lets you share a document as “viewer” (read all) or “commenter” (read all, add comments, no edits) or “editor” (full access). Slack lets you set permissions at the channel level, message level, and even reaction level. Modern applications need this granularity to match real-world authorization complexity.

Example

Real-World Scenario 1: Healthcare Records System A hospital’s electronic health records (EHR) system implements fine-grained authorization: Doctors see all medical data for patients in their care, but not billing details. Nurses see vital signs and medications but not psychiatric notes. Billing staff see insurance and payment information but not diagnoses. Patients see their complete own record but nothing about others. Emergency room doctors can break-glass to access any patient’s critical info but this is logged and audited. Each field in every record has its own access rules.

Real-World Scenario 2: Financial Trading Platform A stock trading application controls access at remarkable granularity: Traders can view and trade securities they’re authorized for (based on licensing). They see their own trading history but not others’. Compliance officers can view all trades but cannot execute any. Risk managers see aggregate positions but not individual trade details. Client advisors see client portfolios they manage but not other clients’. Executives see department-level summaries. Each piece of data has context-dependent access rules.

Real-World Scenario 3: Multi-Tenant SaaS Application A B2B software platform like Salesforce implements tenant isolation plus role-based fine-grained access: Users from Company A can never see Company B’s data (tenant boundary). Within Company A, sales reps see their own opportunities plus their team’s. Managers see their entire division. Admins see everything. But even admins can’t see the “salary” field on employee records unless they’re also in HR. Each object, field, and record can have different permission rules.

Real-World Scenario 4: Government Document Management A government agency’s document system uses classification levels with need-to-know: Documents are marked Public, Internal, Confidential, or Top Secret. But classification alone isn’t enough - you also need “need to know” for that specific topic. A Top Secret clearance doesn’t let you see all Top Secret documents - only those related to your projects. Access also depends on your current role, assignment, and even physical location (some documents only viewable from secure facilities).

Analogy

The Hospital Access Model: In a hospital, your badge doesn’t just open “the hospital” - it opens specific doors based on your role and department. A surgeon’s badge opens operating rooms but not the pharmacy safe. A pharmacist’s opens the safe but not operating rooms. A janitorial badge opens storage closets but not patient rooms. And emergency overrides exist but are logged and reviewed. Fine-grained authorization is this badge system for data.

The Office Building with Room Cards: Imagine an office building where your keycard doesn’t just grant “building access.” Different cards open different rooms. Even within rooms, some cabinets require additional authorization. Some rooms are only accessible during business hours. Certain conference rooms require booking. The CEO’s office requires both a keycard AND the CEO’s presence. This layered, contextual access is what fine-grained authorization provides for data.

The Library with Restricted Sections: A university library has general stacks anyone can access, but rare book collections require special permission. Certain research databases are only available to faculty. Some materials can be viewed in the library but not checked out. Specific items require a request and supervision. Some archives require both credentials AND a research proposal approval. Each resource has its own access rules.

The Netflix Profile System: Even simple consumer apps use fine-grained authorization. Netflix profiles let parents restrict what kids can watch, not at the account level but at the profile level. Kids can browse appropriate content but not change profile settings. Parents can access all content and all settings. The same “Netflix subscription” provides different capabilities to different users based on profile configuration.

Code Example

// Fine-grained authorization example
class FinegrainedAuthz {
  constructor() {
    this.policies = new Map()
  }

  // Field-level authorization
  canReadField(user, resource, fieldName) {
    const field = resource[fieldName]

    // Email: visible to owner or admin
    if (fieldName === 'email') {
      return user.id === resource.userId || user.roles.includes('admin')
    }

    // SSN: only for compliance officers from internal network
    if (fieldName === 'ssn') {
      return (
        user.roles.includes('compliance') &&
        user.network === 'internal' &&
        user.mfaVerified === true
      )
    }

    // Salary: HR or own record
    if (fieldName === 'salary') {
      return (
        user.department === 'hr' ||
        user.id === resource.userId
      )
    }

    // Default: public fields
    return true
  }

  // Operation-level authorization
  canPerformOperation(user, resource, operation) {
    // Delete: only owner or admin, not on locked resources
    if (operation === 'delete') {
      return (
        (user.id === resource.userId || user.roles.includes('admin')) &&
        !resource.isLocked
      )
    }

    // Approve: only managers of same department
    if (operation === 'approve') {
      return (
        user.roles.includes('manager') &&
        user.department === resource.department
      )
    }

    return false
  }

  // Filter response based on permissions
  filterFields(user, resource) {
    const filtered = {}

    for (const [key, value] of Object.entries(resource)) {
      if (this.canReadField(user, resource, key)) {
        filtered[key] = value
      } else {
        // Return masked or null for unauthorized fields
        filtered[key] = this.getMaskedValue(key, value)
      }
    }

    return filtered
  }

  getMaskedValue(fieldName, value) {
    if (fieldName === 'ssn') return '***-**-****'
    if (fieldName === 'email') return '***@***.***'
    if (fieldName === 'salary') return null
    return '[REDACTED]'
  }
}

// API endpoint with fine-grained authorization
app.get('/api/employees/:id', async (req, res) => {
  const authz = new FinegrainedAuthz()
  const user = req.user
  const employee = await db.employees.findById(req.params.id)

  if (!employee) {
    return res.status(404).json({ error: 'Not found' })
  }

  // Apply fine-grained filtering
  const filtered = authz.filterFields(user, employee)

  // Log what was filtered for audit
  const redactedFields = Object.keys(employee).filter(
    key => !(key in filtered) || filtered[key] === null
  )

  if (redactedFields.length > 0) {
    await auditLog.log({
      action: 'field_redaction',
      user: user.id,
      resource: employee.id,
      redactedFields
    })
  }

  res.json(filtered)
})

Security Notes

Standards & RFCs