add compatibility with aws iam auth custom jdbc driver

[mononen]

Support custom drivers and AWS RDS IAM authentication

The problem

OmniSQL dispatches to a native driver by substring-matching the workspace's driver id —
postgres-jdbc contains "postgres", mysql8 contains "mysql". That holds for stock drivers, but
breaks for two increasingly common setups.

1. Custom drivers have opaque ids. A user-defined driver in a DBeaver-compatible client gets a
generated id — often a UUID, e.g. 35379A2C-3AE9-529E-B72B-244C753C055B. It names no engine, so no
routing branch matches, and the connection falls through to the CLI fallback and fails. This affects
any hand-rolled or generated driver, including anything built on the
AWS Advanced JDBC Wrapper, whose URLs also carry
a wrapper sub-protocol (jdbc:aws-wrapper:postgresql://…) that a naive URL parse misreads.

The connection record still identifies the engine, just not in the driver id: provider says
postgresql/mysql, and the JDBC URL names the engine behind any wrapper.

2. IAM-authenticated connections have no password to read. With RDS IAM auth the credential is a
signed token, minted per connection and valid 15 minutes. Nothing is stored in the workspace, so
OmniSQL had nothing to authenticate with, and such connections frequently omit the database username
too. TLS is mandatory — RDS rejects IAM tokens sent in cleartext.

What changed

Driver dialect resolution (src/utils.ts, src/config-parser.ts). When a driver id names no
known engine, fall back to the connection's provider, then to the JDBC URL's sub-protocol, scanning
past wrapper protocols. Resolution happens once at parse time, so all existing routing — direct
queries, pools, transactions, query analysis, schema diff — keeps working unchanged. The raw id is
kept as driverId for display and error messages. Host, port and database are also backfilled from
the JDBC URL when the config omits them.

AWS RDS IAM authentication (src/auth/iam-auth.ts, new). Detected from AWS Advanced JDBC Wrapper
properties (wrapperPlugins: "iam") or an iam-flavoured auth model. Tokens are minted with
aws rds generate-db-auth-token, delegating to the AWS CLI so SSO and role-chained profiles work as
the user already configured them — no new AWS SDK dependency. Tokens are cached 13 minutes under
their 15-minute lifetime, keyed per host/port/user/region/profile.

Long-lived pools refresh rather than expiring: pg receives an async password function and
mysql2 an async mysql_clear_password plugin, each invoked per physical connection.

Where a connection records no username, it is derived from the caller's AWS identity — either the
assumed SSO session name, or, for role-chained profiles whose session name is SDK-generated
(botocore-session-1785446405), by stripping the profile prefix off the role name. Expired SSO
sessions produce an error naming the profile to re-authenticate.

Shared TLS resolution (src/auth/ssl.ts, new). The direct-query and pooled paths each had their
own copy, reading different property locations and disagreeing about what require meant. They now
share one implementation, which also fixes two bugs:

• MySQL TLS options were read only from top-level connection properties, ignoring the nested
  properties block the JSON workspace format writes. PostgreSQL already handled both.
• MySQL REQUIRED implied full certificate verification. Per MySQL's documented ssl-mode
  semantics, REQUIRED encrypts without validating the chain; only VERIFY_CA and
  VERIFY_IDENTITY verify it. The old behaviour cannot work against managed engines like RDS, whose
  CA is absent from the system trust store.

Compatibility

Stock drivers are unaffected: an id that already names its engine is returned untouched, and the
IAM path only activates on connections that declare it.

Two observable changes worth review:

• connection.driver now holds the resolved dialect. list_connections additionally reports
  driverId and provider, but only when resolution was needed.
• The MySQL REQUIRED fix above is a deliberate behaviour change. Connections that set a MySQL TLS
  mode and relied on the previous stricter-than-documented verification would now encrypt without
  verifying. Setting VERIFY_CA/VERIFY_IDENTITY restores it.

No new runtime dependencies. Two new optional environment variables, OMNISQL_AWS_CLI_PATH and
OMNISQL_IAM_TOKEN_TIMEOUT, both documented in the README.

Testing

52 new unit tests (94 total, all passing) covering dialect resolution, JDBC URL parsing, IAM
detection, region and username derivation, token caching, and TLS mode semantics. AWS calls run
through an injectable command runner, so the suite needs no AWS access.

Verified end to end through the MCP tool layer against live Amazon RDS: PostgreSQL 17.7 and MySQL
8.4.8, both via a custom AWS Advanced JDBC Wrapper driver with IAM auth and no stored credentials,
through both the direct-query and pooled-transaction paths.

Checked for regressions against a workspace of 20 connections, 18 of them stock password-based
Postgres and MySQL. Results were identical before and after the change.

[gitguardian]

️✅ There are no secrets present in this pull request anymore.

If these secrets were true positive and are still valid, we highly recommend you to revoke them.
While these secrets were previously flagged, we no longer have a reference to the
specific commits where they were detected. Once a secret has been leaked into a git
repository, you should consider it compromised, even if it was deleted immediately.
Find here more information about risks.

---

^{_{🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.}}