Azure SQL Database credential expiration limits for least-privilege database access

Direct answer

Azure AD access tokens issued for Azure SQL Database (resource https://database.windows.net/) are short-lived—commonly around one hour under default policy, though the exact lifetime depends on current tenant and Conditional Access settings. When that token expires, existing open sessions generally remain usable until the client attempts to re-authenticate, such as when a pooled connection is checked out or a broken connection is re-established. New connection attempts made with an expired token fail until a fresh token is acquired. SQL authentication logins in Azure SQL Database do not enforce password expiration or complexity by default (CHECK_POLICY=OFF), so those passwords remain valid until manually changed or the login is disabled. There is no built-in server-side mechanism to auto-refresh Azure AD tokens for existing sessions, and no native feature that synchronizes SQL auth password rotation with Azure AD token lifetimes.

Likely explanation vs confirmed behavior

The intermittent failures you describe are most likely caused by two client-side behaviors rather than a server-side session kill. First, a cached Azure AD token may be reused past its expires_on value. Second, connection poolers may hold idle connections open beyond the token lifetime and present them to the application without re-validating the credential. The confirmed server-side behavior is that Azure SQL accepts the token at connection establishment and does not proactively terminate an already-established session when the token expires; the failure surfaces on the next authentication attempt.

Steps for this case

1. Use an Azure Identity library that automatically refreshes tokens instead of caching raw tokens in application code.
2. Configure your connection pool maximum lifetime to a value shorter than the observed token lifetime so stale connections are recycled before expiry.
3. For SQL auth scenarios that must coexist with short-lived Azure AD tokens, store the password in Azure Key Vault and retrieve it just-in-time for each connection attempt. Rotate the secret externally; Azure SQL will not expire it on its own.
4. If you need to confirm the current authentication scheme, run SELECT auth_scheme FROM sys.dm_exec_sessions WHERE session_id = @@SPID; on the active session.
5. To confirm SQL auth policy defaults, run SELECT is_policy_checked, is_expiration_checked FROM sys.sql_logins WHERE name = 'your_login'; Both should be 0 when policy checks are off.

Verification and uncertainty

Because token lifetimes are governed by tenant policy, verify the actual expires_on value for a token acquired against https://database.windows.net/ in your environment before sizing pool lifetimes. The commands above are read-only and safe to run. Enabling CHECK_POLICY=ON on a SQL login imposes Windows-style password policy but does not align expiration with Azure AD tokens and may introduce conflicts, so external rotation via a secret store remains the supported path.

One diagnostic detail that would change the recommendation: which client driver and connection pool implementation are you using (for example, Microsoft.Data.SqlClient with ADO.NET pooling, ODBC, or a language-specific pool)? The fix differs: some pools expose token-refresh callbacks, while others require manual lifetime tuning or custom retry logic.