New ReadyTools Access System for CLI & Future Clients

This system creates the foundation for the upcoming ReadyTools Web Assistant 1.3 integration.

With Web Assistant 1.3, eligible Plus and Max subscribers will be able to use their included Pro access through this ReadyTools connection system for supported verification and client access flows.

🔑 Secure ReadyTools Access Keys

Users can now generate dedicated ReadyTools access keys for external clients.

These keys are designed for use by:

• CLI tools

• Browser extensions

• Desktop applications

• ReadyTools Web Assistant

• Future ReadyTools clients

The same access system can be reused across future ReadyTools products instead of building a separate authentication method for every client.

🖥 Built for CLI-Style Authentication

The new system supports a CLI-style connection flow.

A ReadyTools client can open the ReadyTools website with a connection request, after which the user can review and manually approve or reject the connection.

Nothing is granted automatically.

Users are explicitly shown which client is requesting access and which permission scope is being requested before approval.

This makes it possible for future command-line and desktop clients to securely connect to a ReadyTools account without requiring users to manually copy sensitive account credentials.

🔐 Challenge-Based Connection Flow

Automatic connection requests do not place the real access key inside the connection URL.

Instead, the client sends a SHA-256 challenge that ReadyTools can approve after the user confirms the connection.

The actual access key therefore does not need to appear in:

• the URL

• browser history

• referrer information

• connection parameters

🧩 Permission Scopes

ReadyTools Access uses scoped permissions.

The initial system currently supports a limited subscription verification scope:

subscription:read

This means external clients are not automatically given broad access to a ReadyTools account.

The access layer is designed around granting only the minimum permission needed for the connected client.

🔒 Access Keys Are Not Stored in Plain Text

Raw ReadyTools access keys are never stored directly in the database.

When a key is created:

1. ReadyTools generates the access key.

2. The key is hashed using SHA-256.

3. Only the hash and a non-secret shortened hint are stored.

4. The full access key is shown to the user once.

After leaving the creation screen, ReadyTools cannot display the full key again.

This follows the same basic security principle used by many API key and personal access token systems: the server verifies a key without needing to keep the original secret.

👁 One-Time Key Display

Newly generated access keys are shown only once.

Users are prompted to copy the key immediately and store it only inside the ReadyTools client that needs it.

This reduces unnecessary exposure of long-lived credentials.

🛠 Manual Access Key Generation

Users can also create access keys manually.

Each key can have its own recognizable name, such as:

• ReadyTools Web Assistant

• My CLI

• Desktop App

• Browser Extension

This makes it easier to understand which client is using which credential.

🔗 Connected Client Management

A new management section shows connected clients and existing access keys.

Users can see information such as:

• Access key name

• Active or revoked status

• Safe shortened key hint

• Creation date

• Last-used date

• Associated client ID, when available

The original secret key is never displayed in this list.

🚫 Revoke Access at Any Time

Access keys can be revoked directly from ReadyTools settings.

Once revoked, the key can no longer be verified by ReadyTools clients.

This means a user can immediately remove access from an old CLI installation, browser extension, desktop device, or other connected client without changing their main ReadyTools password.

🛡 External Clients Are Treated as Untrusted

The ReadyTools Access system is designed around a minimal-trust model.

External applications are treated as untrusted clients and only receive the minimum information required for the requested verification flow.

Raw access keys are not stored, and connection URLs only contain one-way challenge hashes rather than the original credential.

🌐 Foundation for ReadyTools Web Assistant 1.3

This system is also the foundation for the upcoming ReadyTools Web Assistant 1.3 access model.

In a future Web Assistant 1.3 update, ReadyTools Plus and Max subscribers will be able to connect their ReadyTools account through this system and use the included Pro-level Web Assistant access where supported.

Instead of creating another independent login or subscription system, Web Assistant can verify the user's ReadyTools access through a dedicated scoped credential.

This keeps account access centralized and makes it easier to revoke or manage connected clients from one place.

---

ReadyTools Access is the beginning of a more connected ReadyTools ecosystem.

The goal is to let future ReadyTools apps, extensions, CLI tools, and desktop clients securely recognize your ReadyTools subscription without exposing your main account credentials.