Supporting dynamic SQL Authentication mechanisms (GCP IAM, Azure Workload Identity)

[bradfier]

Apologies for the terrible title - patches welcome.

I was doing some research into what would be required for sqlx::Pool to be able to connect to a MySQL or Postgres instance where authentication was via either GCP Cloud SQL IAM or Azure Managed Workload Identity.

The mode of operation for both of these is pretty simple, rather than have a long-lived Postgres or MySQL password you instead have short-lived credentials mediated by some cloud provider proxy, and issued in response to a query to some API. The token you get back from the API is simply used in the password position in the database protocol.

The 'short-lived' part is interesting here, in almost all cases the sqlx::Pool will be expected to outlive such a token so there needs to be some mechanism to refresh it during the application lifetime.

My question is - for SQLx where would the appropriate place for this logic sit (either as an adapter crate or in-tree if there was interest)? I looked into this for r2d2 for sync usecases and there's a fairly obvious ManageConnection trait that delegates connect() to the implementation which is plugged into the generic pool.

For SQLx could this be achieved by providing a specialised ConnectOptions<Connection = ?>?