> ## Documentation Index
> Fetch the complete documentation index at: https://docs.qonto.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Authentication

> Sign in to Qonto from the CLI, and where the session is kept

The Qonto CLI signs in with **OAuth 2.0**, through the same consent screen you see when you connect any app to Qonto. There is no API key, client secret, or organization ID to copy by hand.

## Sign in

```bash theme={null}
qonto auth login
```

<Steps>
  <Step title="Your browser opens at Qonto">
    Sign in if you are not already, pick the organization to connect, and review what the CLI is asking to do.
  </Step>

  <Step title="You consent">
    Qonto sends your browser back to a page that `qonto` serves on your own machine (`http://127.0.0.1:53683/callback`), which completes the sign-in.
  </Step>

  <Step title="The session is stored">
    The CLI stores the session in your operating system's credential store and prints the scopes you granted. From then on, every command uses that session.
  </Step>
</Steps>

The access token is renewed automatically in the background, so you do not need to sign in again unless you sign out or revoke the access.

Check where you stand at any time:

```bash theme={null}
qonto auth status
```

It shows who you are signed in as, your role, when the access token expires, the granted scopes, and it checks the session against Qonto.

### Signing in from a remote machine

On an SSH session or in a container, the browser on your laptop cannot reach the CLI's local page. Use `--manual`:

```bash theme={null}
qonto auth login --manual --no-browser
```

The CLI prints a sign-in URL. Open it in any browser and consent. The browser then lands on a page that cannot load: copy that page's full address (it starts with `http://127.0.0.1:53683/callback`) and paste it into the terminal.

### Useful login flags

| Flag                     | What it does                                                                                                   |
| ------------------------ | -------------------------------------------------------------------------------------------------------------- |
| `--no-browser`           | Print the sign-in URL instead of opening a browser.                                                            |
| `--manual`               | Do not wait for the browser to come back; paste the address it lands on instead.                               |
| `--organization-id <id>` | Pre-select this organization on the consent screen.                                                            |
| `--scopes <list>`        | Ask for fewer permissions, for example `--scopes organization.read,offline_access` for a read-only session.    |
| `--store-cleartext`      | Keep the session in a file instead of the credential store, see [below](#machines-without-a-credential-store). |

## What the CLI can do on your behalf

The CLI **acts as you**:

* It cannot exceed what your role and your organization's price plan allow. A command your role cannot perform fails with the API's authorization error.
* It is limited to the **scopes** you granted when you signed in. By default the CLI asks for every scope its commands use; [Available OAuth scopes](/get-started/business-api/authentication/oauth/available-scopes) explains each one. To grant more after narrowing them with `--scopes`, sign in again.
* It **cannot make payments**. The CLI is not allowed to request the payment, transfer, or beneficiary scopes, so no session it opens can use them.
* Sensitive actions still require **Strong Customer Authentication**: the command waits while you approve in the Qonto app. See [Strong Customer Authentication](/cli/usage#strong-customer-authentication).

`--help` on any command shows the OAuth scope it needs.

## Where the session is kept

The session (an access token and a refresh token) is stored in your operating system's credential store:

| System  | Store                                   |
| ------- | --------------------------------------- |
| macOS   | Keychain                                |
| Windows | Credential Manager                      |
| Linux   | Secret Service (GNOME Keyring, KWallet) |

Nothing is written to disk in clear text. The configuration file (`~/.config/qonto/config.yaml`) never contains a token.

### Machines without a credential store

A bare server, a container, or a CI runner usually has no credential store, so `qonto auth login` cannot save the session there. On those machines, `--store-cleartext` keeps the session in `~/.config/qonto/credentials.json` instead:

```bash theme={null}
qonto auth login --store-cleartext
```

<Danger>
  That file is **not encrypted**. It is readable only by your user, but anyone who can read it, including a backup, another administrator of the machine, or any program running as you (an AI agent with shell access among them), can act on your Qonto account until you sign out or revoke the access. Use it only on machines you control, with the narrowest `--scopes` list the job allows, and never copy or commit the file.
</Danger>

The CLI never falls back to the file on its own. Once you have signed in this way, pass `--store-cleartext` (or set `QONTO_CLI_STORE_CLEARTEXT=1`) on every command that should use that session. The setting cannot be put in the configuration file.

### Using a token you already have

If you already have an access token, for example in a CI job, set it in `QONTO_CLI_ACCESS_TOKEN`. The CLI uses it for that command instead of the stored session and never saves it. Access tokens expire after an hour and this mode cannot renew them.

## Session commands

| Command                      | What it does                                                                                                                         |
| ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ |
| `qonto auth login`           | Sign in and store the session.                                                                                                       |
| `qonto auth status`          | Show the current session and check it against Qonto.                                                                                 |
| `qonto auth token`           | Print a valid access token (renewing it if needed), for other tools such as `curl`.                                                  |
| `qonto auth refresh`         | Renew the access token now.                                                                                                          |
| `qonto auth logout`          | Revoke the tokens at Qonto and delete the stored session. `--local` only deletes the local copy.                                     |
| `qonto auth revoke-consents` | [Revoke the consents](/api-reference/business-api/authentication/oauth2/revoke-oauth-consents) you gave the CLI for your membership. |

<Warning>
  `qonto auth token` prints a credential to your account. Do not paste it into a chat, a ticket, or a log.
</Warning>

## Reviewing and revoking access

The CLI appears in the **connected apps** section of your Qonto account like any other app you have authorized. Revoking it there stops every session on every machine; the CLI then asks you to sign in again.

`qonto auth logout` cleans up the machine you run it on and revokes that session's tokens. Revoking in Qonto cleans up everywhere. Doing both is the safest way to disconnect completely.

## Sandbox vs production

The CLI connects to the **production** Qonto environment: every command reads and changes your real account.