feat(auth): add Entra ID identity provider integration for Redis client authentication

[bobymicroby]

Description

This PR adds Microsoft Entra ID (formerly Azure AD) authentication support to node-redis through:

1. New @redis/entraid package providing:

• Multiple auth flows (managed identity, client credentials, auth code with PKCE)
• MSAL node library integration
• Auth code PKCE flow sample
• StreamingCredentialsProvider implementation for EntraID

2. Core client authentication refactoring:

• CredentialsProvider interface for async and streaming credentials
• TokenManager and support classes for automated token lifecycle management
• Pluggable authentication mechanism via providers

This enables Redis Enterprise customers to authenticate using Entra ID identities. The architecture also allows custom CredentialProvider implementations for third-party Identity Provider integration.

Checklist

[x] npm test passes (new tests added for token management / streaming credential provider )
[ ] New code is mostly tested, except for some pending test coverage in the EntraID package.
[ ] docs are in progress

[bobymicroby]

Note: I'm considering adding a sync-credentials-provider variant as well:

export interface SyncCredentialsProvider {
  readonly type: 'sync-credentials-provider';
  credentials: () => BasicAuth
}

Would appreciate thoughts on whether this negligible performance optimization is worth the additional API surface area.

[dhensby]

Looks lovely, and much more thorough and thought-out than my minimal-effort approach in #2849

❤️

[dhensby]

Suggested change

	import { TokenManager, TokenManagerConfig, TokenStreamListener, RetryPolicy, IDPError } from './token-manager';
	export { TokenManager, TokenManagerConfig, TokenStreamListener, RetryPolicy, IDPError };
	export { TokenManager, TokenManagerConfig, TokenStreamListener, RetryPolicy, IDPError } from './token-manager';

I believe these import/export calls can be unified - though this may be a style-guide/preference thing.

[bobymicroby]

@dhensby Sure, it makes total sense to unify them.

The idea behind the 'barrel' file initially was to create a proper export so users can import from @redis/client/authx :

"exports": {
    ".": {
      "types": "./dist/index.d.ts",
      "default": "./dist/index.js"
    }, 
    "./authx": {
      "types": "./dist/lib/client/authx/index.d.ts",
      "default": "./dist/lib/client/authx/index.js"
    },

But then I found out that we already have imports in peer packages using paths like @redis/client/lib/ and even @redis/client/dist/ and many others... This can be addressed in one of these ways:

• Adding more explicit exports (not ideal):

"./index": {
      "types": "./dist/index.d.ts",
      "default": "./dist/index.js"
    },
    "./authx": {
      "types": "./dist/lib/client/authx/index.d.ts",
      "default": "./dist/lib/client/authx/index.js"
    },
    "./lib/commands/generic-transformers": {
      "types": "./dist/lib/commands/generic-transformers.d.ts",
      "default": "./dist/lib/commands/generic-transformers.js"
    },
    "./dist/*": {
      "types": "./dist/*.d.ts",
      "default": "./dist/*.js"
    },
    "./lib/errors": {
      "types": "./dist/lib/errors.d.ts",
      "default": "./dist/lib/errors.js"
    }

• Not using exports at all, keeping it as is and creating a barrel file just for user convenience
• Creating a separate submodule containing only the authx support classes

For now, I've decided to stick with not using exports, but I'm considering creating a separate submodule for the authx support classes.

[dhensby]

async setTimeout is now built into node, there used to be a utility in redis for this which I think was removed in preference of the built-in functionality which is being used extensively in other tests.

[bobymicroby]

Thanks @dhensby! I'll switch to using the built-ins

[dhensby]

node allows synthetic clocks, so it may be preferred to use them over a custom faked clock?

[bobymicroby]

Thanks @dhensby! You're the second node developer to suggest using node's synthetic timers. While I have a slight preference for avoiding global method replacements like setTimeout/Date.now() , you're right - it would be better to align with common practices. I'll switch to using Node's synthetic timers instead of my custom Clock approach.

[dhensby]

Would it be worth using TS 5.2 "native" Disposable interface (https://www.typescriptlang.org/docs/handbook/release-notes/typescript-5-2.html#using-declarations-and-explicit-resource-management)

[bobymicroby]

@dhensby makes total sense, i will use the built-in Disposable, thanks for the tip!

[dhensby]

Note: I'm considering adding a sync-credentials-provider variant as well:

I don't think there is any need for a sync-credentials-provider. async functions that instantly resolve are treated essentially as sync in the node runtime and if await is used instead of .then() (which it is) non-asynchronous functions could still be provided if the consumer wanted to take that risk (which they shouldn't) and it'll "just work".

[bobymicroby]

Note: I'm considering adding a sync-credentials-provider variant as well:

I don't think there is any need for a sync-credentials-provider. async functions that instantly resolve are treated essentially as sync in the node runtime and if await is used instead of .then() (which it is) non-asynchronous functions could still be provided if the consumer wanted to take that risk (which they shouldn't) and it'll "just work".

@dhensby I agree - I don't think adding a sync-credentials-provider would provide meaningful value. While Node.js optimizes immediately-resolving Promises, shaving off a few nanoseconds (possibly by avoiding the microtask queue) probably isn't worth the additional API surface area. Let's keep the API surface focused and minimal.