cc @ItalyPaleAle

Due to the long lived TCP connections however we need to ensure to manually renew the AAD token in a background goroutine and reinit the connection.

I don't think this is needed as long as the connection is alive. The token should be refreshed only if the connection needs to be re-established (that's what we do for Postgres and want to do for MySQL)

If the token expires, the Azure Cache for Redis server will terminate the connection and it expects a renewed token to keep the connection alive.

If the token expires, the Azure Cache for Redis server will terminate the connection and it expects a renewed token to keep the connection alive.

Since AAD tokens have a lifetime of 1hr, are you saying that connections with Azure Cache for Redis are always terminated every hour forcefully?

(This doesn't seem to be the case for Azure DB for Postgres or Azure SQL AFAICT)

Right, the client applications create long-running, TCP connections to Redis which are expected to be alive for the duration of the application ideally. We typically see connections alive and running for weeks without interruption. So yes, if the redis server does not receive a renewed token before the 1 hour is up, the connection will be terminated.

@shpathak-msft Ok, I understand now.

In practice, does that mean we need to re-send the AUTH command periodically, when we get a new token (like every hours or so)?

Do you know if there's a Go SDK that implements this already?

Looks like go-redis supports AUTH command but you would need to call the AUTH command periodically and supply renewed token.

@shpathak-msft can you confirm sending the AUTH command periodically will actually work with your system? Or do we completely need to terminate the connection?

Sending auth command periodically works. All our code samples and the StackExchange.Redis extension package send auth command periodically. This periodic auth command was the workaround to avoid terminating the connection as closing/creating connections is expensive on the server side and we want to avoid terminating as much as possible.

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged (pinned, good first issue, help wanted or triaged/resolved) or other activity occurs. Thank you for your contributions.

Is this issue addressing all Redis components, or just the state store?
I was looking at using Azure AD auth with the lock component.

Interesting ! I would like to try it

/assign

@berndverst @ItalyPaleAle @shpathak-msft , Since we want to refresh token too frequently do we have to always request it from Azure AAD ? or we can use some random token to save that frequent request to cloud ?

It needs to be an actual AAD token as it will be validated on the server side.

@dstarkowski this issue will impact all Dapr Redis components

To complete Entra ID / Azure AD support in Redis components someone needs to complete the PR #3238 or start from scratch.

The idea is to take the azureidentity library to request an azcore.AzureTokenCredential and call GetToken on this to request the token. (we have shared code for this already in the common/authentication/azure folder which is used by all components). This token needs to be sent to Redis via the Redis client AUTH command. Before the token expires (say 2 minutes before expiry) a new token needs to be requested via GetToken and once against sent via AUTH. This needs to be done in the background until eternity.