* churn(test): use redislabs/client-libs-test for testing This switches our testing infrastructure from redis/redis-stack to redislabs/client-libs-test Docker image across all packages. This change also updates the default Docker version from 7.4.0-v1 to 8.0-M04-pre. * churn(test): verify CONFIG SET / GET compatibility with Redis 8 - Add tests for Redis 8 search configuration settings - Deprecate Redis Search CONFIG commands in favor of standard CONFIG - Test read-only config restrictions for Redis 8 * churn(test): handle Redis 8 coordinate precision in GEOPOS - Update GEOPOS tests to handle increased precision in Redis 8 (17 decimal places vs 14) - Add precision-aware coordinate comparison helper - Add comprehensive test suite for coordinate comparison function * test(search): adapt SUGGET tests for Redis 8 empty results - Update tests to expect empty array ([]) instead of null for SUGGET variants - Affects sugGet, sugGetWithPayloads, sugGetWithScores, and sugGetWithScoresWithPayloads * test(search): support Redis 8 INFO indexes_all field - Add indexes_all field introduced in Redis 8 to index definition test * refactor!(search): simplify PROFILE commands to return raw response - BREAKING CHANGE: FT.PROFILE now returns raw response, letting users implement their own parsing * test: improve version-specific test coverage - Add `testWithClientIfVersionWithinRange` method to run tests for specific Redis versions - Refactor TestUtils to handle version comparisons more accurately - Update test utilities across Redis modules to run tests against multiple versions, and not against latest only
@redis/entraid
Secure token-based authentication for Redis clients using Microsoft Entra ID (formerly Azure Active Directory).
Features
- Token-based authentication using Microsoft Entra ID
- Automatic token refresh before expiration
- Automatic re-authentication of all connections after token refresh
- Support for multiple authentication flows:
- Managed identities (system-assigned and user-assigned)
- Service principals (with or without certificates)
- Authorization Code with PKCE flow
- Built-in retry mechanisms for transient failures
Installation
npm install "@redis/client@5.0.0-next.6"
npm install "@redis/entraid@5.0.0-next.6"
Getting Started
The first step to using @redis/entraid is choosing the right credentials provider for your authentication needs. The EntraIdCredentialsProviderFactory class provides several factory methods to create the appropriate provider:
createForSystemAssignedManagedIdentity: Use when your application runs in Azure with a system-assigned managed identitycreateForUserAssignedManagedIdentity: Use when your application runs in Azure with a user-assigned managed identitycreateForClientCredentials: Use when authenticating with a service principal using client secretcreateForClientCredentialsWithCertificate: Use when authenticating with a service principal using a certificatecreateForAuthorizationCodeWithPKCE: Use for interactive authentication flows in user applications
Usage Examples
Service Principal Authentication
import { createClient } from '@redis/client';
import { EntraIdCredentialsProviderFactory } from '@redis/entraid/dist/lib/entra-id-credentials-provider-factory';
const provider = EntraIdCredentialsProviderFactory.createForClientCredentials({
clientId: 'your-client-id',
clientSecret: 'your-client-secret',
authorityConfig: {
type: 'multi-tenant',
tenantId: 'your-tenant-id'
},
tokenManagerConfig: {
expirationRefreshRatio: 0.8 // Refresh token after 80% of its lifetime
}
});
const client = createClient({
url: 'redis://your-host',
credentialsProvider: provider
});
await client.connect();
System-Assigned Managed Identity
const provider = EntraIdCredentialsProviderFactory.createForSystemAssignedManagedIdentity({
clientId: 'your-client-id',
tokenManagerConfig: {
expirationRefreshRatio: 0.8
}
});
User-Assigned Managed Identity
const provider = EntraIdCredentialsProviderFactory.createForUserAssignedManagedIdentity({
clientId: 'your-client-id',
userAssignedClientId: 'your-user-assigned-client-id',
tokenManagerConfig: {
expirationRefreshRatio: 0.8
}
});
Important Limitations
RESP2 PUB/SUB Limitations
When using RESP2 (Redis Serialization Protocol 2), there are important limitations with PUB/SUB:
- No Re-Authentication in PUB/SUB Mode: In RESP2, once a connection enters PUB/SUB mode, the socket is blocked and cannot process out-of-band commands like AUTH. This means that connections in PUB/SUB mode cannot be re-authenticated when tokens are refreshed.
- Connection Eviction: As a result, PUB/SUB connections will be evicted by the Redis proxy when their tokens expire. The client will need to establish new connections with fresh tokens.
Transaction Safety
When using token-based authentication, special care must be taken with Redis transactions. The token manager runs in the background and may attempt to re-authenticate connections at any time by sending AUTH commands. This can interfere with manually constructed transactions.
✅ Recommended: Use the Official Transaction API
Always use the official transaction API provided by the client:
// Correct way to handle transactions
const multi = client.multi();
multi.set('key1', 'value1');
multi.set('key2', 'value2');
await multi.exec();
❌ Avoid: Manual Transaction Construction
Do not manually construct transactions by sending individual MULTI/EXEC commands:
// Incorrect and potentially dangerous
await client.sendCommand(['MULTI']);
await client.sendCommand(['SET', 'key1', 'value1']);
await client.sendCommand(['SET', 'key2', 'value2']);
await client.sendCommand(['EXEC']); // Risk of AUTH command being injected before EXEC
Error Handling
The provider includes built-in retry mechanisms for transient errors:
const provider = EntraIdCredentialsProviderFactory.createForClientCredentials({
// ... other config ...
tokenManagerConfig: {
retry: {
maxAttempts: 3,
initialDelayMs: 100,
maxDelayMs: 1000,
backoffMultiplier: 2
}
}
});