DEV Community: Samiat Akande

Building Trust Into Authentication: Practical Access Control Patterns for Modern Apps

Samiat Akande — Thu, 25 Jun 2026 07:35:00 +0000

Most apps think they are secure because they have login pages.

But authentication is only the first step.

Once a user is logged in, your app still needs to answer a bigger question:

What should this user be allowed to do?

That is where access control comes in.

If your authentication is weak, users cannot trust your system.

If your authorization is weak, your system cannot trust its users.

Authentication versus authorization

These two are often confused.

Authentication means who are you.

Authorization means what can you do.

A 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.

Basic role based access control

One of the simplest and most practical patterns is role based access control, or RBAC.

def can_view_sensitive_data(role):
    allowed_roles = ["admin", "privacy_officer", "security_lead"]
    return role in allowed_roles

user_role = "engineer"

if can_view_sensitive_data(user_role):
    print("Access granted")
else:
    print("Access denied")

This is basic, but it makes the rule explicit.

Why this matters

Without access control, systems often end up with too much exposure.

That leads to:

Overexposed dashboards
Too many internal permissions
Accidental data leaks
Poor auditability
Broken trust

When users know permissions are handled carefully, they trust the platform more.

Prefer least privilege

A strong access model follows the principle of least privilege.

Give each user only the access they need, and nothing more.

That means:

Support staff should not see all customer records by default
Engineers should not have production access unless required
HR data should be tightly segmented
Admin permissions should be rare and auditable

Scope access by action, not just by role

Sometimes role alone is not enough.

A user may be allowed to view a record but not delete it. Or view their own profile but not other users’ profiles.

def can_perform(action, role):
    permissions = {
        "admin": {"view", "edit", "delete"},
        "manager": {"view", "edit"},
        "user": {"view"}
    }

    return action in permissions.get(role, set())

print(can_perform("delete", "manager"))
print(can_perform("view", "user"))

This gives you more control than a simple allow or deny model.

Separate public, private, and sensitive data

A good trust model also separates data by sensitivity.

For example:

Public data such as name and display photo
Private data such as email and phone
Sensitive data such as salary, ID number, or health data

Your app should treat these categories differently.

def serialize_profile(profile, access_level):
    public_data = {
        "name": profile["name"],
        "username": profile["username"]
    }

    private_data = {
        "email": profile["email"]
    }

    sensitive_data = {
        "salary": profile["salary"]
    }

    if access_level == "public":
        return public_data
    elif access_level == "private":
        return {**public_data, **private_data}
    elif access_level == "sensitive":
        return {**public_data, **private_data, **sensitive_data}

This kind of separation makes security easier to enforce.

Log access to sensitive actions

Trust also comes from accountability.

If sensitive data is accessed, there should be an audit trail.

def log_access(user_id, action):
    print(f"User {user_id} performed {action}")

In 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.

Practical trust checklist

Before shipping an app, ask:

Are login and session flows secure?
Are permissions role based and action based?
Is sensitive data segmented?
Are defaults restrictive?
Is access logged?
Can we explain permissions clearly to users and admins?

Final thought

Authentication gets users into the system.

Authorization keeps the system trustworthy.

And in modern applications, trust is not just a security feature. It is part of the product.

Privacy by Design in Your API: How to Collect Less Data Without Breaking UX

Samiat Akande — Tue, 09 Jun 2026 06:29:00 +0000

When developers think about privacy, they often think about legal compliance, consent banners, or policy pages.

But privacy starts much earlier than that, at the API layer.

Every time your backend asks for a phone number, date of birth, location, or optional profile field, you are making a design decision. If you collect too much data by default, you increase risk, reduce trust, and make your system harder to maintain.

The good news is that privacy by design does not have to make your product worse. In many cases, it makes your API cleaner, safer, and easier to reason about.

Why collecting less data matters

The more data you collect, the more you have to protect.

That means more storage, more access control, more breach risk, more compliance burden, and more user distrust if something goes wrong.

A developer friendly privacy approach is simple:

Only collect what you need to deliver value.

Bad pattern: collecting everything up front

user_profile = {
    "name": "Amina",
    "email": "amina@example.com",
    "phone": "07000000000",
    "dob": "1995-01-01",
    "address": "123 Main Street",
    "location": "Lagos",
    "gender": "female"
}

This kind of structure is common in early stage products. The thinking is usually: let us ask for everything now, just in case we need it later.

But just in case is not a good privacy strategy.

Better pattern: collect only what is required

def build_profile(name, email, phone=None):
    profile = {
        "name": name,
        "email": email
    }

    if phone is not None:
        profile["phone"] = phone

    return profile

user_profile = build_profile("Amina", "amina@example.com")
print(user_profile)

This is small, but the principle matters.

Optional data should stay optional unless it is truly needed.

Use explicit field validation

Instead of accepting a giant payload and filtering it later, validate the exact fields you expect.

ALLOWED_FIELDS = {"name", "email", "phone"}

def sanitize_payload(payload):
    return {k: v for k, v in payload.items() if k in ALLOWED_FIELDS}

incoming = {
    "name": "Amina",
    "email": "amina@example.com",
    "phone": "07000000000",
    "location": "Lagos",
    "dob": "1995-01-01"
}

clean_payload = sanitize_payload(incoming)
print(clean_payload)

This helps reduce accidental over collection and makes your API behavior more predictable.

Design for progressive disclosure

Instead of asking for everything at sign up, collect data over time as the user gets value.

For example:

Sign up with name and email
Ask for phone only when needed for verification
Ask for location only for location based features
Ask for profile details only when the user chooses to personalize their account

This improves trust and reduces friction.

Think about data minimisation in responses too

Privacy is not only about what you collect. It is also about what you return.

Avoid sending unnecessary user data back in API responses.

def user_response(user):
    return {
        "id": user["id"],
        "name": user["name"]
    }

Do not return internal fields like password hashes, access tokens, internal notes, audit flags, or admin only metadata.

A simple rule for developers

Before adding a field to your request or database schema, ask:

Do we need this field right now?
What feature depends on it?
Who will access it?
How long will we keep it?
What happens if it leaks?

If the answer is unclear, do not collect it yet.

Final thought

Privacy by design is not just about avoiding problems.

It is about building systems that users can trust and teams can maintain.

And often, the most elegant API is the one that asks for the least.