Context
An access token proves an application's identity when it opens an Azure SQL connection. Connection pooling reuses physical connections to avoid paying that setup cost for every query. Problems arise when token acquisition and pool identity are designed independently, creating excessive pools or unreliable authentication as processes run longer.
This guide concerns Microsoft.Data.SqlClient applications. Prerequisites are the deployed package version, authentication configuration and an application test environment. Collect connection counts and sanitized exception details. Never log raw access tokens, connection passwords or token-bearing request headers.
1. Determine the selected authentication path
Inspect whether the application uses a supported Authentication connection-string mode, sets AccessToken directly, or supplies AccessTokenCallback. These approaches have configuration restrictions and should not be combined casually. Check the version actually shipped in the application artifact, not only a developer workstation's package list.
Record the credential source and intended security context. A local developer credential succeeding does not demonstrate that the deployed managed identity has database access. Keep authorization review separate from token lifetime behavior so a missing database principal is not mistaken for expiration.
2. Examine pool identity and object lifetime
When AccessToken is assigned directly, its literal value participates in the pool key. Replacing it repeatedly can create distinct pools. SqlClient does not receive the token's expiration through that property. Review how the application acquires fresh tokens and handles affected pools, particularly with a nonzero minimum pool size.
For supported versions, AccessTokenCallback supplies a token together with its expiration. Reuse the same callback delegate and credential object when connections should share the same security context and pool. Creating a new callback closure for every request can defeat that intent. Never reuse one callback in a way that returns different identities for identical authentication parameters.
3. Verify renewal under realistic process lifetime
Run the test long enough to cross token renewal, using a representative mixture of pooled reuse and new physical connections. Record authentication failures, pool counts and time spent opening connections. Test an idle period followed by a new workload, since that sequence can expose problems hidden during continuous traffic.
Prefer the driver's supported authentication and refresh behavior over custom timers that indiscriminately clear all pools. If a correction changes identity selection, test authorization for every intended database. Dispose logical connections normally so they return to the appropriate pool. Keep retry budgets bounded while investigating recurring authentication errors.
Diagnostic checkpoints
| Observation | Possible cause | Next evidence |
|---|---|---|
| Pool count grows with token acquisition | Literal token changes pool key | Authentication implementation |
| New callback each request | Delegate identity fragments pools | Callback object lifetime |
| Local works, deployed login fails | Different security context | Deployed principal mapping |
| Failures follow long idle period | Renewal or stale pool behavior | Token lifetime and driver traces |
Illustrative scenario
A hypothetical API acquires a token separately for every request and assigns it to AccessToken. Its database connection count grows unexpectedly across process lifetime. The team reviews a supported callback design with stable object reuse and tests renewal before release. This fictional example does not attribute performance gains to a particular customer.
Operational verification
Acceptance requires stable pool behavior, successful new connections across renewal and correct identity on the database side. Compare sanitized telemetry before and after deployment and retain a rollback to the previous authentication implementation.
Document driver versions, credential ownership and pool lifetime assumptions in the SOP. Monitor authentication failures separately from query timeouts and pool acquisition delays. Revalidate when upgrading SqlClient or changing tenant, managed identity or application lifetime, because these changes affect the authentication context and renewal contract.
Explore Clouvenix cloud security for implementation and operational handover.