Authentication, Authorization & Security: Designing Secure FDE Solutions

Every solution with users needs answers to two questions: who are you? (authentication) and what are you allowed to do? (authorization). Together they form the core of application security — which is not a feature added at the end, but a set of decisions woven through every layer of the design. This tutorial covers both halves of access control, then the design-level defenses around them: data protection, network boundaries, input handling, secrets, and dependencies.

Table of Contents

• Authentication vs. Authorization
• Passwords Done Right
• Sessions vs. Tokens
• Single Sign-On and Identity Providers
• Multi-Factor Authentication
• Authorization Models and Role-Based Access Control
• Where to Enforce Authorization
• Security Is a Design Property
• Think Like an Attacker: Threat Modeling
• Protecting Data: At Rest, In Transit, In Use
• Network and Boundary Design
• Input Validation and Injection Attacks
• Secrets Management
• Dependency and Supply-Chain Security
• Logging and Auditing Security Events
• Working Example: Access and Security Design for the Delivery Solution

Authentication vs. Authorization

The two words get mixed up constantly, but they're separate layers:

Authentication always comes first — you can't decide what someone may do until you know who they are. But a system can authenticate you perfectly and still authorize you badly; the two must each be designed.

Authentication checks something the user knows (password, PIN), has (phone code, hardware key), or is (fingerprint, face). Most business systems start with password + one extra factor. The mechanism matters less than the plumbing around it: how credentials are stored, how identity is carried after login, and what happens when things expire or fail.

Passwords Done Right

Passwords are still the backbone of most logins, and most of the rules are about protecting them:

• Never store passwords — store hashes. A hash is a one-way transformation: you can check a password against it, but you can't turn it back into the password.

# Conceptual — use a proven library (e.g., bcrypt/argon2), never invent this
stored_hash = hash_password("correct-horse-battery")   # at signup

# at login:
if verify_password(submitted_password, stored_hash):
    log_user_in()

• Use a slow, salted hashing algorithm (bcrypt, scrypt, Argon2). "Slow" is the point — it makes guessing attacks expensive.
• Hash on the server. Whatever the frontend does, the server must hash again; the password should never be stored or logged in plain text.
• Give good failure messages — but not too good. "Invalid email or password" is right; "No account with that email" leaks which emails exist.

Common Mistake: building password storage from scratch with MD5 or SHA-256 alone. Use a purpose-built password-hashing function from a maintained library — this is not a place for creativity.

Sessions vs. Tokens

After login, the server needs to recognize the user on every following request. Two standard designs:

Session-based (server-side): the server creates a session record and gives the browser a session ID cookie.

Login → server stores session {user: maria, expires: 8h}
        browser gets cookie: session_id=abc123
Later → every request carries the cookie;
        server looks up abc123 to know it's Maria

Token-based (client-side, usually JWT): the server signs a token containing the user's identity; the client sends it back on each request.

Login → server signs token {sub: maria, role: dispatcher, exp: 8h}
Later → every request carries: Authorization: Bearer <token>
        server verifies the signature — no lookup needed

Note: for a typical FDE web solution, sessions are simpler and easier to revoke. Tokens shine when a mobile app or several services need to verify identity without sharing a session store. Either way: keep lifetimes short (hours, not months) and send credentials only over HTTPS.

Single Sign-On and Identity Providers

In customer engagements you'll often be told: "our people log in with the company account." That's Single Sign-On (SSO) — your app delegates authentication to an identity provider (IdP) the customer already runs: Microsoft Entra ID (Azure AD), Okta, Google Workspace.

The standard protocol is OAuth 2.0 / OpenID Connect, and the flow looks like this:

1. User clicks "Sign in" in your app
2. Your app redirects to the customer's IdP login page
3. User authenticates THERE (your app never sees the password)
4. IdP redirects back with a signed token: "this is Maria, she's real"
5. Your app verifies the token and creates its own session

Why this matters for FDEs: SSO is often a hard customer requirement, and it's a gift — no password storage, no reset flow, and when the customer's IT disables someone centrally, your app is covered automatically. When an IdP exists, delegate authentication instead of building it (the build-vs-buy logic from Tutorial 3 applies perfectly here).

Multi-Factor Authentication

Multi-factor authentication (MFA) requires a second factor at login — typically a code from an authenticator app, an SMS, or a hardware key. It neutralizes the most common attack: a stolen or guessed password.

Design-wise, MFA is a second step between "password checked" and "session created":

Password OK  →  MFA challenge  →  code verified  →  session issued
                    (user is NOT logged in yet)

Enable it at least for admin and privileged roles; many customers require it for everyone.

Authorization Models and Role-Based Access Control

Authorization runs on every request, not just at login: "this user, right now, is allowed to do this thing to this data." The three models you'll meet:

RBAC covers most business applications. Start with a small set of roles tied to real jobs, not to screens:

viewer      → read dashboards and reports
operator    → viewer + create/edit records
dispatcher  → operator + reassign deliveries
admin       → dispatcher + manage users and settings

Two rules keep RBAC sane:

• Grant to roles, never to individuals. "Maria can reassign" becomes "dispatchers can reassign, and Maria is a dispatcher." When Maria changes jobs, you change one assignment, not twenty permissions.
• Least privilege. Everyone starts with the minimum that does their job. Adding access later is easy; discovering someone had too much is an incident.

Where to Enforce Authorization

A permission system is only as good as where it's checked. The rule: enforce in the backend, at the data boundary — not in the UI.

❌ Hiding the "Reassign" button from non-dispatchers
   (the API still accepts the call — anyone can send it)

✅ The API checks the caller's role on every request:
   if user.role not in ("dispatcher", "admin"):
       return 403 Forbidden

Hiding UI elements is fine for usability; it is never security. The server must reject unauthorized calls even if no button was ever shown.

Best Practice: centralize the check. One middleware/decorator like @require_role("dispatcher") on each route beats scattered if-statements — scattered checks are how one forgotten endpoint becomes a hole.

Security Is a Design Property

Access control is the front door; the rest of security is making sure there are no windows nobody noticed. A system's security is mostly decided before the first line of code: where the data lives, who can reach it, what crosses the boundary, and how identity is checked. Bolted-on security — a firewall here, a scan there — patches holes in a shape that was already wrong.

Three principles sit under everything that follows:

• Least privilege — every user, service, and connection gets the minimum access that does its job.
• Defense in depth — no single layer is trusted to be enough; an attacker who passes one wall meets another.
• Assume breach — design so that if one part is compromised, the damage is contained and detectable.

Note: in FDE work, security is also a trust topic. The customer's IT and compliance teams will review your design. A solution that answers their questions on paper — data location, access control, encryption — clears procurement; one that can't, stalls there.

Think Like an Attacker: Threat Modeling

Threat modeling is the habit of asking, for each part of the design, "how would this be abused?" A simple walk-through covers most of it:

1. Draw the diagram (Tutorial 2's deployment diagram is ideal).
2. List the entry points — every arrow crossing a boundary: public URLs, APIs, file uploads, webhooks, admin logins.
3. For each entry point ask: Can an outsider reach it? Can a legitimate user abuse it? What data can they touch?
4. Rank what you find by two questions: how likely is it, and how bad is it if it happens?
5. Fix the high-likelihood, high-impact items first.

A useful lens for step 3 — the classic categories of abuse:

You don't need a formal framework to get the value — an hour with the diagram asking these questions catches the large majority of design-level holes.

Protecting Data: At Rest, In Transit, In Use

Data protection splits into three states, each with its own rule:

In transit — data moving over a network. Rule: HTTPS/TLS everywhere, no exceptions. Every URL, every API call, every webhook, including internal traffic when it crosses a network you don't fully control. Plain-HTTP endpoints are how credentials and data get intercepted.

At rest — data sitting in storage. Rules:

• Enable encryption at rest on databases and object storage (usually a managed-service checkbox).
• Encrypt sensitive fields (national IDs, payment data) at the application level when policy demands it.
• Minimize what you keep. Data you never stored can never leak. Retention limits are a security feature.

In use — data being processed or displayed. Rules: mask sensitive values in the UI (show •••• 4821, not the full card), restrict who can export, and never write sensitive data into logs.

Best Practice: start from the data, not the technology. List the sensitive data your solution touches, classify it (public / internal / confidential / regulated), and let the classification set the protection level. Regulated data (health records, payment data) carries legal obligations — surface those early, because they can reshape the whole architecture.

Network and Boundary Design

The network layer decides who can even reach your components:

• Not everything needs a public address. Only the front door (load balancer / API gateway) faces the internet. Databases, queues, and internal services live in private networks with no public IP.

Internet ──▶ [ Load balancer (public) ]
                    │
             private network
                    │
        ┌───────────┼───────────┐
        ▼           ▼           ▼
   [ API servers ] [ workers ] [ database ]   ← no public access

• Firewall rules as least privilege: each component accepts connections only from what needs it. Workers reach the database; the dashboard does not.
• The customer's boundary matters. In FDE work part of the system often sits inside the customer's network. Their firewall, VPN, and proxy rules become your constraints — map them on the deployment diagram and get IT's sign-off early.

Input Validation and Injection Attacks

The most common application-level attacks all share one trick: untrusted input is treated as code or commands. The family name is injection.

SQL injection — input becomes part of a database query:

# ❌ Dangerous: user input glued into the query
query = f"SELECT * FROM users WHERE email = '{email}'"
# email = "x' OR '1'='1"  →  returns every user

# ✅ Safe: parameterized query — input stays data, never becomes SQL
query = "SELECT * FROM users WHERE email = %s"
db.execute(query, (email,))

Other members of the family:

The universal rule: validate all input at the boundary — type, length, format, allowed values — and treat everything from outside (users, APIs, files, webhooks) as untrusted forever, not just at login.

Common Mistake: trusting "internal" input. Data that came from your own database was once typed by a user. Validate at every trust boundary, not only the first one.

Secrets Management

Secrets are the credentials that open everything else: database passwords, API keys, tokens, signing keys. The rules are short and absolute:

• Never put secrets in code or in the repository. Not even "temporarily" — git history is forever.
• Store them in a secrets manager or environment variables, injected at deploy time.
• One secret per purpose, per environment. The staging database key is not the production key; the ERP key is not the email key.
• Rotate them. Change secrets on a schedule and immediately when someone with access leaves or a leak is suspected.
• Scope them down. An API key that can only read deliveries is a smaller disaster than a master key when it leaks.

❌  API_KEY = "sk-live-9f8e7d..."        # in app.py, committed to git
✅  API_KEY = os.environ["ERP_API_KEY"]   # injected by the platform

Note: before your first commit, check that a .gitignore covers .env and config files. A leaked cloud key found by automated scanners can cost real money within minutes — this is the most common real-world security incident in small projects.

Dependency and Supply-Chain Security

Modern applications are mostly other people's code: frameworks, libraries, packages. Each dependency is a trust decision — a vulnerability in a library you import is a vulnerability in your system.

The discipline:

• Keep dependencies up to date. Most known vulnerabilities have patches; running old versions is choosing the risk.
• Run automated scans (Dependabot, npm audit, pip-audit, Snyk) and actually act on critical findings.
• Lock your versions (lockfiles) so builds are reproducible and a surprise upgrade can't break — or compromise — production.
• Take fewer dependencies. Every package is attack surface and maintenance. For a small utility, twenty lines of your own code can beat a dependency.

Logging and Auditing Security Events

Assume-breach design needs detection: you must be able to see an attack happening and reconstruct it afterwards.

Log at minimum:

• Logins — successes and failures, with user and source address.
• Permission denials (403s) — a pattern of them is someone probing boundaries.
• Changes to privileged data — who changed what, when (the audit trail from Tutorial 5).
• Admin actions — role changes, user creation, configuration changes.

Two rules keep logs useful:

• Never log secrets or sensitive data. A log full of passwords and tokens is itself a breach waiting to happen.
• Protect the logs. An attacker who can edit the logs erases the evidence. Keep logs append-only and, ideally, shipped off the machine they're written on.

Working Example: Access and Security Design for the Delivery Solution

Requirements from discovery: drivers confirm deliveries on phones; dispatchers reassign; the office watches a dashboard; only finance exports invoicing data; customer phone numbers and proof photos are confidential.

Authentication design:

Authorization design (RBAC):

Enforcement: every API route carries a role check; the "own deliveries" rule for drivers is a data-scope check (delivery.driver_id == user.id) on top of the role check. The UI hides what you can't do, but the API refuses it either way.

The security layers around it:

The pattern to notice: none of this is exotic technology. It's standard features of managed platforms and frameworks, configured deliberately. That's the realistic bar for FDE security work — disciplined use of boring, proven defenses.