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

Azure SQL Database supports least-privilege access by mapping Azure AD users or groups to contained database users and assigning built-in roles such as db_datareader or db_datawriter, avoiding server-level logins. Under current Azure AD integration, access tokens issued for this resource have a limited lifetime—commonly described as approximately one hour, though exact durations depend on current Azure AD policy—after which new connections fail until a fresh token is acquired. By contrast, SQL authentication logins in Azure SQL Database do not enforce password expiration or complexity policies, so those passwords remain valid until explicitly changed or the login is disabled.

This creates an unresolved boundary for applications that combine minimal standing privileges with long-running sessions or cached credentials. Client-side token caching may reuse an expired token, making it difficult to distinguish whether repeated authentication failures originate from the token lifetime itself or from cache invalidation behavior.

What are the documented limits for re-authenticating a contained database user when a connection or cached credential outlives the Azure AD token lifetime? How does Azure SQL Database handle token expiration for existing sessions versus new connection attempts? Is there a supported way to align SQL authentication password rotation with short-lived Azure AD tokens without introducing higher-privilege server logins?