{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreidob5z44r524y2hv6s6yebc6pkcyhxfiloojlam4yvowgja2z7apq",
    "uri": "at://did:plc:25rdn5elo5izoxrmtis34zuk/app.bsky.feed.post/3mp3wzzdbeqa2"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreia72ipzhbjpmgos3iuo5kpxvklxcfkgqs57mj3xjxu6c73yh2jjoy"
    },
    "mimeType": "image/webp",
    "size": 375660
  },
  "path": "/samiatakande11/building-trust-into-authentication-practical-access-control-patterns-for-modern-apps-55pc",
  "publishedAt": "2026-06-25T07:35:00.000Z",
  "site": "https://dev.to",
  "tags": [
    "ai",
    "security",
    "webdev",
    "productivity"
  ],
  "textContent": "Most apps think they are secure because they have login pages.\n\nBut authentication is only the first step.\n\nOnce a user is logged in, your app still needs to answer a bigger question:\n\nWhat should this user be allowed to do?\n\nThat is where access control comes in.\n\nIf your authentication is weak, users cannot trust your system.\n\nIf your authorization is weak, your system cannot trust its users.\n\n###  Authentication versus authorization\n\nThese two are often confused.\n\nAuthentication means who are you.\n\nAuthorization means what can you do.\n\nA user might successfully log in, but that does not mean they should be able to view every record, edit every profile, or access sensitive data.\n\n###  Basic role based access control\n\nOne of the simplest and most practical patterns is role based access control, or RBAC.\n\n\n\n    def can_view_sensitive_data(role):\n        allowed_roles = [\"admin\", \"privacy_officer\", \"security_lead\"]\n        return role in allowed_roles\n\n    user_role = \"engineer\"\n\n    if can_view_sensitive_data(user_role):\n        print(\"Access granted\")\n    else:\n        print(\"Access denied\")\n\n\nThis is basic, but it makes the rule explicit.\n\n###  Why this matters\n\nWithout access control, systems often end up with too much exposure.\n\nThat leads to:\n\n  1. Overexposed dashboards\n  2. Too many internal permissions\n  3. Accidental data leaks\n  4. Poor auditability\n  5. Broken trust\n\n\n\nWhen users know permissions are handled carefully, they trust the platform more.\n\n###  Prefer least privilege\n\nA strong access model follows the principle of least privilege.\n\nGive each user only the access they need, and nothing more.\n\nThat means:\n\n  1. Support staff should not see all customer records by default\n  2. Engineers should not have production access unless required\n  3. HR data should be tightly segmented\n  4. Admin permissions should be rare and auditable\n\n\n\n###  Scope access by action, not just by role\n\nSometimes role alone is not enough.\n\nA user may be allowed to view a record but not delete it. Or view their own profile but not other users’ profiles.\n\n\n\n    def can_perform(action, role):\n        permissions = {\n            \"admin\": {\"view\", \"edit\", \"delete\"},\n            \"manager\": {\"view\", \"edit\"},\n            \"user\": {\"view\"}\n        }\n\n        return action in permissions.get(role, set())\n\n    print(can_perform(\"delete\", \"manager\"))\n    print(can_perform(\"view\", \"user\"))\n\n\nThis gives you more control than a simple allow or deny model.\n\n###  Separate public, private, and sensitive data\n\nA good trust model also separates data by sensitivity.\n\nFor example:\n\n  1. Public data such as name and display photo\n  2. Private data such as email and phone\n  3. Sensitive data such as salary, ID number, or health data\n\n\n\nYour app should treat these categories differently.\n\n\n\n    def serialize_profile(profile, access_level):\n        public_data = {\n            \"name\": profile[\"name\"],\n            \"username\": profile[\"username\"]\n        }\n\n        private_data = {\n            \"email\": profile[\"email\"]\n        }\n\n        sensitive_data = {\n            \"salary\": profile[\"salary\"]\n        }\n\n        if access_level == \"public\":\n            return public_data\n        elif access_level == \"private\":\n            return {**public_data, **private_data}\n        elif access_level == \"sensitive\":\n            return {**public_data, **private_data, **sensitive_data}\n\n\nThis kind of separation makes security easier to enforce.\n\n###  Log access to sensitive actions\n\nTrust also comes from accountability.\n\nIf sensitive data is accessed, there should be an audit trail.\n\n\n\n    def log_access(user_id, action):\n        print(f\"User {user_id} performed {action}\")\n\n\nIn a real system, this would write to secure logs, not just stdout. But the principle is the same. Sensitive actions should not disappear without a trace.\n\n###  Practical trust checklist\n\nBefore shipping an app, ask:\n\n  1. Are login and session flows secure?\n  2. Are permissions role based and action based?\n  3. Is sensitive data segmented?\n  4. Are defaults restrictive?\n  5. Is access logged?\n  6. Can we explain permissions clearly to users and admins?\n\n\n\n###  Final thought\n\nAuthentication gets users into the system.\n\nAuthorization keeps the system trustworthy.\n\nAnd in modern applications, trust is not just a security feature. It is part of the product.",
  "title": "Building Trust Into Authentication: Practical Access Control Patterns for Modern Apps"
}