Blog Post

Azure Database Support Blog
2 MIN READ

Lesson Learned #533: Intermittent Azure SQL Database Connectivity and Authentication Issues

Jose_Manuel_Jurado's avatar
Aug 01, 2025

While working on a recent service request, we helped a customer troubleshoot intermittent connection and authentication failures when accessing Azure SQL Database using Active Directory (Entra ID) authentication from a Java-based application using HikariCP with JDBC/ODBC.

While working on a recent service request, we helped a customer troubleshoot intermittent connection and authentication failures when accessing Azure SQL Database using Active Directory (Entra ID) authentication from a Java-based application using HikariCP with JDBC/ODBC.

They got the following error: 

com.zaxxer.hikari.pool.HikariPool$PoolInitializationException: Failed to initialize pool: Failed to authenticate.. 
Request was throttled according to instructions from STS. Retry in 29701 ms. 
java.sql.SQLTransientConnectionException: HikariPool-application1 - Connection is not available, request timed out after

The first insight was focusing in the error message: Request was throttled according to instructions from STS. Retry in 29701 ms. This message seems it is  returned by the Azure Active Directory Security Token Service (STS) when the client is sending too many token requests in a short period of time, exceeding the allowed threshold.

 

We don't have all the details about, but, in high-concurrency environments (e.g., multiple threads, large connection pool) causes each thread to independently request a new token and we could reach a limit in this service, even, if the connection pool retries frequently or fails authentication, the number of token requests can spike. This is the reason, that HikariCP tries to initialize or refresh connections quickly, as many threads attempt to connect at once, and all trigger token requests simultaneously, STS throttling is reached. 

 

In order to avoid this situation, could be different topics, like, ensure our application caches tokens and reuses them across threads, using Managed Identity, increase the retry after delay, or perhaps, depending on HikariCP configuration, pre-warm connections gradually. Of course, discuss with your EntraID administration is other option. 

 

Published Aug 01, 2025
Version 1.0

1 Comment

  • BrettWoolridge's avatar
    BrettWoolridge
    Copper Contributor

    Author of HikariCP here. Thanks for writing this up. I'd like to note that v7.0.0. just released and includes support for a user-specified HikariCredentialsProvider class. HikariCP will call this whenever it needs to create a new connection to allow the kind of token generation you are discussing. However, the onus is on the implementer to wisely re-use and refresh tokens. STS tokens are valid for a specific period of time, rather than being one-time-use, so the implementation should probably refresh the token on a background schedule thread and in-between simply return whatever the "current" token is. Hopefully this will be helpful to developers, but a naive implementation that always requests a new token will run into the same issues identified here. Best regards.