add support for token provider #1587

deyaaeldeen · 2025-07-16T23:29:04Z

I understand that this repository is auto-generated and my pull request may not be merged

Changes being requested

This PR introduces a new tokenProvider option to the OpenAI client, enabling dynamic token retrieval for authentication scenarios where API keys need to be refreshed or obtained at runtime.

Additional context & links

Changes

New Feature: tokenProvider Option

Added TokenProvider type definition: () => Promise<AccessToken>
Added AccessToken interface with token: string property
Added tokenProvider option to ClientOptions interface
Implemented token provider logic in the _setToken() method

Key Benefits

Dynamic Authentication: Supports scenarios where tokens expire and need to be refreshed
Enhanced Security: Tokens can be retrieved just-in-time rather than stored statically
Enterprise Integration: Enables integration with corporate identity providers and token management systems
Flexible Authentication: Provides an alternative to static API keys for environments requiring dynamic credentials

Implementation Details

Client Construction:

tokenProvider and apiKey are mutually exclusive - only one can be provided
If neither is provided, an error is thrown requiring one of the two authentication methods
Browser usage automatically allowed when using tokenProvider (sets dangerouslyAllowBrowser: true)

Token Management:

_setToken() method now returns a boolean indicating if a token was successfully retrieved
Token provider is called on every request preparation via prepareOptions()

Usage Example

const client = new OpenAI({
  tokenProvider: async () => {
    // Fetch token from your auth service
    const response = await fetch('/api/auth/token');
    const data = await response.json();
    return { token: data.access_token };
  }
});

Backward Compatibility

This change is fully backward compatible. Existing code using apiKey continues to work unchanged. The new tokenProvider option is purely additive.

src/client.ts

RobertCraigie · 2025-07-28T21:00:43Z

src/client.ts

@@ -438,6 +457,31 @@ export class OpenAI {
    return Errors.APIError.generate(status, error, message, headers);
  }

+  async _setToken(): Promise<boolean> {


nit: I think "refresh" is a better verb than "set" here?

The decision to refresh is taken by the input function and not by this method, i.e. it is not guaranteed that the token will be refreshed if this method is called. However, let me know if you feel strongly about it and I can update the name.

I do dislike _set but don't feel strongly about it being called _refresh - I find it weird that a method called _setX() doesn't actually take any arguments.

fwiw I was also framing "refresh" as in, refresh the apiKey property - not necessarily do a full token refresh.

wdyt about _callApiKey()? I don't think that's great either... my main fud with _setApiKey() is that the return value is not intuitive imo and it'd be great if we could find a name that makes that work

Addressed in 577ebc6.

RobertCraigie · 2025-08-26T17:44:43Z

src/client.ts

 export interface ClientOptions {
  /**
   * Defaults to process.env['OPENAI_API_KEY'].
   */
-  apiKey?: string | undefined;
-
+  apiKey?: string | ApiKeySetter | undefined;


The docstring should mention the new function behaviour

Good point, addressed in 577ebc6.

RobertCraigie · 2025-08-26T17:52:41Z

src/client.ts

@@ -385,7 +386,7 @@ export class OpenAI {

    this._options = options;

-    this.apiKey = apiKey;
+    this.apiKey = typeof apiKey === 'string' ? apiKey : 'Missing Key';


suggestion: should probably be something like <not set yet>?

actually, we should move API_KEY_SENTINEL our of the azure specific file and use that

It is only used once here so I am not sure if there is value to have it in a constant var.

RobertCraigie · 2025-08-26T18:18:09Z

tests/lib/azure.test.ts

      let fail = true;
-      const testFetch = async (url: RequestInfo, req: RequestInit | undefined): Promise<Response> => {
+      const testFetch = async (url: any, { headers }: RequestInit = {}): Promise<Response> => {


q: why did you have to use any?

Good point, addressed in 577ebc6.

RobertCraigie · 2025-08-26T18:41:42Z

src/client.ts

@@ -438,6 +457,31 @@ export class OpenAI {
    return Errors.APIError.generate(status, error, message, headers);
  }

+  async _setToken(): Promise<boolean> {


I do dislike _set but don't feel strongly about it being called _refresh - I find it weird that a method called _setX() doesn't actually take any arguments.

fwiw I was also framing "refresh" as in, refresh the apiKey property - not necessarily do a full token refresh.

wdyt about _callApiKey()? I don't think that's great either... my main fud with _setApiKey() is that the return value is not intuitive imo and it'd be great if we could find a name that makes that work

RobertCraigie · 2025-08-26T18:42:12Z

src/beta/realtime/websocket.ts

@@ -49,6 +50,10 @@ export class OpenAIRealtimeWebSocket extends OpenAIRealtimeEmitter {

    client ??= new OpenAI({ dangerouslyAllowBrowser });

+    if (typeof (client as any)?._options?.apiKey !== 'string') {
+      throw new Error('Call the create method instead to construct the client');


nit: this error message could be more helpful

also, wait does this work? because _setApiKey() doesn't mutate options, won't this check always return true if you pass in a function?

should we instead define the client.apiKey fallback string as a constant and check that? e.g. if (client.apiKey === API_KEY_MISSING) { ...

We want to check whether the user provided a function or a string at the time of constructing the OpenAI client. If the user provided a function, we can't call it here. if (client.apiKey === API_KEY_MISSING) wouldn't work because _setApiKey might have been called setting client.apiKey to a token that might have expired by the time the realtime client is being used.

error messages are updated in 390c131

good point about the token potentially being expired but I think my other question still stands? does this check work as intended? because we don't mutate _options, so if you originally pass in a function then typeof (client as any)?._options?.apiKey !== 'string' would always be true?

Yes, that is the intention. If the user passed in a function, they can't construct an RT client using the constructor.

oh I see what you mean now. The constructor is called in the factory method too. Let me address this.

RobertCraigie · 2025-08-26T18:52:25Z

src/client.ts

+      try {
+        const token = await apiKey();
+        if (!token || typeof token !== 'string') {
+          throw new Errors.OpenAIError(
+            `Expected 'apiKey' function argument to return a string but it returned ${token}`,
+          );
+        }
+        this.apiKey = token;
+        return true;
+      } catch (err: any) {
+        if (err instanceof Errors.OpenAIError) {
+          throw err;
+        }
+        throw new Errors.OpenAIError(
+          `Failed to get token from 'apiKey' function: ${err.message}`,
+          // @ts-ignore
+          { cause: err },
+        );
+      }


having a try catch around the whole block and then checking inside the catch if we threw isn't great, could we instead just either put the try catch just around the await apiKey()? or await apiKey().catch(...)?

Good point, addressed in 577ebc6.

deyaaeldeen force-pushed the feat/token-provider branch 2 times, most recently from b4dd476 to f514473 Compare July 16, 2025 23:40

tetraprod approved these changes Jul 18, 2025

View reviewed changes

RobertCraigie reviewed Jul 28, 2025

View reviewed changes

src/client.ts Outdated Show resolved Hide resolved

RobertCraigie reviewed Jul 28, 2025

View reviewed changes

deyaaeldeen force-pushed the feat/token-provider branch from f514473 to a5ce6ac Compare August 22, 2025 17:08

add support for token provider

9086c73

deyaaeldeen force-pushed the feat/token-provider branch 2 times, most recently from 1453757 to b623760 Compare August 22, 2025 18:09

address feedback

0307ed5

deyaaeldeen force-pushed the feat/token-provider branch from b623760 to 0307ed5 Compare August 22, 2025 18:17

fix test

b6102b3

RobertCraigie reviewed Aug 26, 2025

View reviewed changes

deyaaeldeen added 2 commits August 26, 2025 13:31

address feedback

577ebc6

update error messages

390c131

add support for token provider #1587

Are you sure you want to change the base?

add support for token provider #1587

Conversation

deyaaeldeen commented Jul 16, 2025

Changes being requested

Additional context & links

Changes

Key Benefits

Implementation Details

Usage Example

Backward Compatibility

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!