0

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

4
  • For context: is this a web app? Or a native application on some platform (mobile, desktop, …)?
    – amon
    Commented Oct 19, 2022 at 19:28
  • 1
    Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer.
    – Community Bot
    Commented Oct 19, 2022 at 19:44
  • 1
    @amon I've updated the question. Thanks for your time.
    – bonum_cete
    Commented Oct 19, 2022 at 21:00
  • 1
    What is the projected cost of using an allegedly heavy handed approach? What is the projected cost of having to develop a second solution just to avoid said allegedly heavy handed approach? By cost, I don't just mean money; it can be effort, or complexity, or moving deadline, ...
    – Flater
    Commented Oct 20, 2022 at 4:29

5 Answers 5

2

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}`);
1
  • 1
    I agree with the overall advice, but I do consider "the simplest thing that works" to also account for the possibility that reusing an existing solution, even if it would be considered overkill if you'd still have to develop it from scratch for this project, can be a valid simplification of the development process. I infer from OP's question that the other approach already exists ("I've written authentication for multiple users, it seems heavy handed to use the same kind of architecture")
    – Flater
    Commented Oct 24, 2022 at 21:46
0

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.
1
  • 2
    You have to balance now vs later though. Thinking about and building for all these things that may or may not happen in the future might be smart design, but it also often results in software that never gets out the door. Commented Oct 21, 2022 at 7:02
0

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.

0

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.

1
  • As it’s currently written, your answer is unclear. Please edit to add additional details that will help others understand how this addresses the question asked. You can find more information on how to write good answers in the help center.
    – Community Bot
    Commented Oct 21, 2022 at 17:27
0

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.

1
  • Killing off everyone else would make talking about "an app that only has one user" rather pointless because any app would have only one user then..... Commented Apr 15, 2023 at 10:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.