Authentication for an app that only has one user

Question

I'm going to write a blog app for myself, and though I've written authentication for multiple users. It seems heavy handed to use the same kind of architecture for one user.

The only alternatives to having a table/document with one user (myself) for auth would be an environment variable to check. However, I'm not sure that is a good idea.

Is there agreed upon patterns for such an app?

Edit: This is for a web app using NextJS, React and MongoDB

Answer 1

Do the simplest thing that works. From my perspective, this would be a HTTP Basic-Auth challenge, which the server compares with expected credentials. The expected credentials could e.g. be provided via an environment variable.

HTTP has a built-in authentication mechanism with the Authorization header. If you use a proxy server, it's probably easiest to configure there (e.g. via .htaccess files in Apache). But it's also easy to implement via a middleware function that performs the following:

• if the client has sent a header Authorization: Basic CREDENTIALS:
  • decode and check the credentials
  • if the credentials match, continue processing the request
• otherwise, respond immediately with 401 Unauthorized, including a WWW-Authenticate: Basic realm="Access to the web app" header.

From the client perspective, this leads to the following flow:

• the first time the web app is visited, the site responds with an error, and the browser shows a popup asking for username+password. The browser dialog may or may not show the realm string to the user.
• upon entering the correct username+password, the page is re-loaded
• the browser will remember these credentials for all subsequent requests on that origin
• the Authorization header will also be sent for subresource and fetch() requests on that origin

Since the user interface for this is provided by the browser, it can be super easy to develop.

Disadvantages:

• only username+password supported
• can't log out directly (but can forget credentials by deleting “site data” for that origin, or whatever your browser calls it)

Providing the expected credentials to the app through environment variables is likely to be perfectly fine. This allows you to easily rotate credentials, if necessary. For software that is supposed to run on localhost, it's also feasible to generate a secure password during app startup and to print the password to be used to the log. You can easily generate cryptographically secure passwords on Linux via a shell command like head -c 32 /dev/urandom | base64, corresponding to the NodeJS JavaScript code:

import { open } from "fs/promises";
const f = await open("/dev/urandom");
const { buffer } = await f.read({ buffer: Buffer.alloc(32) });
const password = buffer.toString('base64');
console.log(`your password is ${password}`);

Or equivalently in a cross-platform manner:

import { randomBytes } from "crypto";
const password = randomBytes(32).toString('base64');
console.log(`your password is ${password}`);

Answer 2

While there's is no official consensus for the security of such an app specifically, it is widely beleived that security is somewhere that shortcuts should never be taken. As the app is only for your own consumption, and presuming you can be sure that the userbase will not expand, I recommend choosing whatever standard security practices best suits your personal needs.

In a nutshell, regardless of the number of users, authentication should be minimally sufficient to fend of the 'potential' of any unauthenticated access. It may well seem heavy handed to put a single user record in a database but it's my opinion that is just good design, and certaily re-usable too.

Answer 3

Just because you start out thinking that you'll be the App's only user doesn't mean it will stay that way.
Think "multi-user" from the outset.

Why?

• Nifty little utility Apps like this have a habit of "leaking" out [into the workplace] and getting used by other people.
• Any web app is a potential target for hackers.
  Proper security is a must and your hacker makes for a second [unauthorised] user.
• Any app that is only available to one person isn't going to last very long, especially if (Lord forbid) something happens to that one person.
  Always have the capability for someone else to "step in", avoiding this "Single Point of Failure.
  Always make sure that you (and your internal / external Auditors) can differentiate between what the two of you were doing.

Answer 4

I'd almost suggest having more security since you know it's just for you, not less. If you've built authenticated systems before then you know what you're doing so probably easiest and best to just implement something similar with you as the only user. As an extra layer you could even whitelist IPs if you tend to always access it from the same network. Depends what's actually in the DB and the impact of someone who's not you seeing it.

Answer 5

For "an app that only has one user" to be true the app must be secured somehow. That could be done by anything from authentication built into the app to killing off everyone else on the planet.

Something, somewhere, has to reduce the users from anyone to you. Doesn't have to be done in the app. You could just install it on one computer behind a locked door. But if it isn't done somewhere then it's an app anyone can use.