DataGrip and Database Server: Credential Expiration and Session Persistence

Question

DataGrip manages database connectivity through JDBC drivers, utilizing internal password-safe mechanisms or system keychains to store authentication data. While the IDE maintains persistent connections to improve performance, the lifecycle of these sessions is governed by the target database server's timeout and credential expiration policies.

A challenge arises when credentials expire on the server side while a DataGrip session remains active. Because the IDE relies on the driver's handling of the authentication handshake, there is uncertainty regarding how the client behaves when a persistent connection is severed due to credential rotation or expiration without a manual trigger of the 'Test Connection' feature.

Does DataGrip automatically trigger a credential refresh prompt when the JDBC driver reports an authentication failure on an existing session?
What is the expected behavior for session recovery when utilizing system keychain integration versus the internal master password storage?

Tasadduq Burney · Answer

Credential Refresh and Session Recovery
DataGrip does not proactively monitor server-side credential expiration. Instead, it reacts to the SQLException returned by the JDBC driver when a request is made over a severed or invalidated session. If the database server terminates a persistent connection due to credential expiration, DataGrip will typically trigger a credential refresh prompt only when you attempt to execute a new statement or manually refresh the database tree.

Expected Behavior by Storage Method
The mechanism used to store passwords (System Keychain vs. Internal Storage) does not change the trigger for session recovery, but it changes how the IDE retrieves the secret during the reconnection attempt:

System Keychain Integration: DataGrip requests the stored secret from the OS (e.g., macOS Keychain, Windows Credential Manager). If the OS grants access, the IDE attempts a silent reconnect. If the stored secret is outdated, the connection fails, and the IDE prompts the user for the new password.
Internal Master Password Storage: DataGrip retrieves the secret from its own encrypted database. If a Master Password is configured and the IDE is currently locked, the reconnection will be blocked until the Master Password is provided, regardless of whether the database credentials themselves are valid.

Technical Explanation
Because DataGrip operates as a client to the JDBC driver, it is decoupled from the server's internal authentication lifecycle. A "persistent" connection is essentially a TCP socket held open; the server may mark the session as expired internally, but the socket may remain open until a packet is sent and the server responds with an authentication error. The IDE cannot "know" the credentials have expired until the driver reports a failure during a handshake or query execution.

Verification Steps
To verify this behavior in your specific environment (as JDBC driver implementations vary), perform the following scoped test:

Establish a connection to a test database.
Manually expire the password or rotate the credentials on the server side.
Leave the DataGrip session idle for several minutes.
Execute a simple SELECT 1; statement and observe if the IDE immediately prompts for credentials or returns a driver-specific error.

Diagnostic Detail Needed: To provide a more precise answer regarding silent retries, please specify the JDBC driver version and the database engine (e.g., PostgreSQL 15, Oracle 21c), as some drivers attempt internal retries before bubbling the error up to the IDE.

DataGrip and Database Server: Credential Expiration and Session Persistence

1 answer

Credential Refresh and Session Recovery

Expected Behavior by Storage Method

Verification Steps

Your perspective belongs here.

0 question comments