Simplifying CLI software authentication

I have recently been working on a CLI-first uptime monitoring tool and explored alternative ways of authentication for command-line programs. Binocs users install the binary and manage their checks and notification channels from their terminal. The monitoring engine runs on globally distributed Binocs servers and does all the heavy lifting, while the CLI client communicates with the monitoring engine via its REST API. The CLI client has to authenticate with the API somehow.

Initially, I implemented the classic authentication workflow, where users generated keypairs on the Binocs website, and fed the key pair to the client program upon executing the binocs login command. The CLI program then stored the key pair locally and later exchanged it with the API for an Authentication bearer token.

I expected users to read, think, decide, click, copy & paste twice, and mentally conclude the process. We promised to make developers' lives easier. And then, we placed this heavy burden on them before providing them with any value at all.

So I began thinking about how to simplify the authentication workflow.

The solution

Every Binocs CLI installation since version 0.7.0 (released on September 26, 2022) automatically generates a Client Key token and saves it locally in the user's dotfiles. The program later exchanges the Client Key for a JWT behind the scenes, and the JWT is used as the standard Authorization bearer token for all protected API calls.

The crucial part here is to securely associate the Client Key with the user's Binocs account. We can do this simply by providing the user with a link containing the Client Key and asking them to click it. Just visiting the URL does the job as long as the user is logged in to Binocs in their browser.

And, that's it. Instead of requiring users to grasp the concepts of Access and Secret Keys, asking them to generate a key pair, then interacting with the CLI program to feed it the key pair, we have them follow one link, and they're done with it, and can start using the product.

Is this approach less secure than the original? I don't see any problem.

Is this way simpler for the user? It certainly is.

The bottom line

As users (and programmers), we got used to handling and storing usernames, passwords, and generated keys. Yet there are more straightforward ways for users and programs to authenticate with web services. And perhaps these more straightforward methods are more secure simply because there are fewer processes and less code involved.