The Business Reality: Security Is Expected, Never Discussed
When South African business owners commission client-facing software, they come with a clear feature brief. They want clients to log in, view invoices, sign documents, book appointments, or manage their accounts. What almost never appears in that brief is the question: how exactly will you protect those accounts?
Authentication is the front door of every digital product that requires a login. It is the system that decides who gets in, what they are allowed to see, and whether a session is still valid. Most business owners assume it is handled correctly by default, because they hired a developer. Some of the time, that assumption holds. Too often, it does not, and the gap only becomes visible when something goes wrong.
Why It Is Costing You More Than You Realise
A security failure at the authentication layer is not just a technical problem. It is a client relationship problem, a regulatory problem, and potentially a legal one. Under South Africa's Protection of Personal Information Act (POPIA), businesses that process personal information have a legal obligation to protect it. A breach caused by weak authentication exposes you to regulatory action, not just reputational damage. Your clients trust your platform with their names, email addresses, financial records, and signed legal documents. That trust is not rebuilt easily once it is broken.
Consider a realistic scenario. A professional services firm builds a client portal where clients can view invoices, upload confidential documents, and sign contracts electronically. The developer implements a standard username and password login. But session tokens are set to never expire, passwords are stored in a weakly encrypted format, and there is no two-factor authentication. A former junior staff member who had access to a shared testing account still knows the credentials. They access the portal from home, download several clients' financial records, and the firm does not notice for three weeks. When a client calls to ask why their documents were accessed at 2 a.m., there is no clean answer.
The session token never expiring is not a fringe edge case. It is an extremely common default when authentication is not treated as a first-class concern. The same applies to weak password storage, missing lockout policies, and sessions that do not invalidate on logout. These are the gaps that cause harm, and they are all preventable with deliberate architecture decisions made before a single line of application code is written.
How Authentication Actually Works
To have the right conversation with your technology partner, you need a clear map of what authentication actually involves. This is not a technical deep-dive for developers. It is a plain-English explanation of the terrain every business owner should understand before signing off on a client-facing platform.
Authentication vs authorisation: two separate systems
Authentication answers one question: who is this user? Authorisation answers a different question: what is this user allowed to do? These are separate systems, and confusing them is one of the most common mistakes in client-facing software. A user can be correctly authenticated (the system knows who they are) and still incorrectly authorised, seeing data that belongs to another client. Both systems need to be designed deliberately, not assumed to be handled because a login page exists.
How a login works, step by step
When a user enters their email and password, the application takes the submitted password and runs it through a hashing function, which converts it into a fixed-length string that cannot be reversed. It then compares that hash to the one stored in the database for that email address. If they match, the user is authenticated. The system creates a session, which is a record of the authenticated state, and stores a session token in the user's browser. Every subsequent request the user makes includes that token, which the server validates before returning data.
This process depends on two things being done correctly: the password must be stored as a proper cryptographic hash, and the session token must be managed securely throughout its entire lifecycle. Both of these are where gaps appear in systems that were not designed carefully from the start.
Password storage and why hashing matters
Storing a password in plain text is the most fundamental failure mode in authentication design. If your database is ever accessed without authorisation, every user's password is immediately exposed in a form an attacker can use directly. The industry standard is to hash passwords using algorithms designed specifically for this purpose. Bcrypt and Argon2 are the two most widely used, and both are intentionally slow to compute, which makes automated guessing attacks enormously expensive to run at scale. They also add a random value called a salt to each password before hashing, which means two users with the same password produce entirely different stored hashes, preventing bulk attacks using precomputed lookup tables.
A modern authentication provider handles all of this automatically. If your developer is building a custom authentication system from scratch and cannot articulate why that is necessary, that is a risk worth raising before your platform goes live.
Sessions, cookies, and tokens
Once a user is logged in, the application needs to remember that state for the duration of their visit. Sessions can be managed in two main ways: server-side sessions stored in the database and referenced by a session ID in a cookie, or stateless tokens such as JSON Web Tokens (JWTs) that contain signed user information and do not require a database lookup on every request. Both are valid when implemented correctly.
The critical issue in either case is lifecycle management. Sessions and tokens must expire after a defined period of inactivity. They must be invalidated when a user logs out. When a user changes their password or their account is flagged, all existing sessions for that account should be terminated immediately. A session token that never expires, or one that remains valid after the user logs out, is an open access window with no time limit. This is a design decision, not an accident, and it needs to be made deliberately.
Two-factor authentication
Two-factor authentication adds a second verification step after the password, typically a time-limited code sent to the user's phone or generated by an authenticator app. Even if an attacker knows the correct username and password, they cannot log in without access to the second factor. For any portal handling financial records, legal documents, or sensitive client information, two-factor authentication should not be optional. It should be the default, offered during onboarding and required for access to high-sensitivity areas of the platform.
Social login and OAuth
Many modern applications offer login via Google or Microsoft. This uses a protocol called OAuth, which delegates authentication to a trusted third party and returns a verified identity token. When implemented correctly, this is extremely secure, since you are relying on Google's or Microsoft's identity infrastructure rather than your own. The trade-off is a dependency on that provider and a slightly more complex integration. Whether it is appropriate depends on your user base and the nature of the platform you are building.
The vulnerabilities your software should defend against
Brute force attacks involve automated systems attempting thousands of password combinations per second against a login endpoint. The defence is account lockout after a defined number of failed attempts, combined with rate limiting at the API layer so the login endpoint cannot be hit faster than a human would reasonably type.
Credential stuffing is a variation that uses real username and password combinations leaked from other breaches. Users who reuse passwords across services are particularly vulnerable. Requiring strong unique passwords, offering two-factor authentication, and checking submitted passwords against known breach databases substantially reduces exposure.
Session hijacking occurs when an attacker intercepts or steals a valid session token. HTTPS encryption prevents interception on secure connections. Binding sessions to device characteristics and invalidating tokens on suspicious activity patterns adds a further layer of protection. None of these defences are exotic. They are standard practice in platforms built by teams that treat security as part of the architecture, not an add-on after launch.
The SEO and GEO Layer: Why Security Signals Matter for Visibility
Authentication and security are not just technical concerns. They are trust signals that affect how your business appears in both traditional search results and AI-generated responses. Google's E-E-A-T framework, which assesses Experience, Expertise, Authority, and Trust across your digital presence, treats security as part of overall site credibility. HTTPS is the minimum. A platform with a strong, well-documented technical foundation signals legitimacy to both search engines and the clients who research you before making contact.
On the Generative Engine Optimisation side, AI search tools are increasingly used to answer business software questions. When someone asks what makes a secure client portal, or what authentication approach is right for a professional services platform, the AI pulls from sources that demonstrate credibility and depth on those specific topics. Publishing clear, expert-level content on how authentication works signals to AI systems that your business understands what it is building. That signals reliability in an environment where trust is hard to fake at scale.
For business owners building client-facing software, demonstrating security knowledge builds credibility with clients evaluating technology partners and improves visibility in the AI search landscape where vendor decisions are increasingly being researched before a first call is ever made.
What Good Authentication Actually Looks Like
Use an established authentication provider, not a custom system. Tools like Supabase Auth, Auth0, and Firebase Authentication handle credential storage, session management, password resets, email verification, and two-factor authentication out of the box, maintained by dedicated security teams. Custom authentication systems introduce risk without adding competitive value. There is no business advantage in building your own password hashing implementation.
Enforce strong password policies and make two-factor authentication the default. Minimum length requirements, complexity rules, and breach detection should be standard. Two-factor authentication should be offered at onboarding and required for portals handling sensitive data. The cost of implementing it upfront is minimal. The cost of retrofitting it after a breach is not.
Manage session lifecycle deliberately and completely. Tokens must expire. Sessions must be invalidated on logout. If a user changes their password, all other active sessions must terminate. These are not advanced features. They are baseline requirements that get missed when authentication is treated as something that can be improved later. Later, in this context, usually means after a client has called to report a problem.
Implement role-based access control at the database level. Every user should only be able to access the data and functions their role permits. Access rules enforced only at the application layer can be bypassed by bugs or by a compromised route. Enforcing the same rules at the database level means the data itself refuses to return to requests that have not been verified. Defence in depth is the principle: no single layer is the only line of protection.
Log authentication events and monitor for anomalies. Failed login attempts, unusual session patterns, and access from unfamiliar locations should all be recorded. For sensitive platforms, automated alerts on anomalous patterns are worth building from day one. You cannot respond to a breach you have not detected, and you cannot detect what you have never logged.
The CodeLab One Approach
Every client-facing platform we build at CodeLab One uses Supabase Auth as the authentication layer. It handles password hashing using bcrypt, session management, email verification, password reset flows, and user management through a battle-tested, open-source system maintained by a dedicated security team. We do not build custom authentication from scratch, because the risk of making a subtle but consequential error outweighs any theoretical benefit of doing so in-house.
Beyond the auth provider itself, we add layers that address the real-world failure modes we see in client-facing software. We implement explicit session refresh token handling in every protected route. Rather than assuming a session management library will silently handle token renewal as a side effect, our middleware explicitly reads the refresh token from the current session and forces a real refresh when needed. This prevents a class of silent failure where a user appears logged in on their screen but their server-side session has actually expired, causing authenticated actions to fail with no clear signal to the user or the platform owner. We also build role-based access control directly into the database using row-level security policies, so even if an application-level bug were to bypass the application's own access checks, the database would still enforce the correct data boundaries.
When we build web applications and custom software for clients, authentication decisions made at the architecture stage affect every interface that platform will ever have. Those decisions also affect the underlying data layer where client information is stored, which we cover in detail in our article on how databases power every business application. The API layer is where every authenticated request flows, and understanding how authentication tokens move through that layer is part of understanding your own platform's security posture. For clients planning a client-facing build, starting with a thorough brief is the first step: our guide on how to write a software brief that gets you an accurate quote covers exactly how to surface the security requirements your developer needs to hear before they begin.
Authentication is not a feature that gets added when the platform is otherwise finished. It is part of the foundation. At CodeLab One, it is always one of the first conversations, never one of the last.
Find Out Exactly Where You Stand
If your business is ready to build, improve, or grow its online presence, book your free website or app audit with CodeLab One today and find out exactly where you stand.
