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

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

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

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?

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) { ...

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(...)?

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

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

add support for token provider #1587

add support for token provider #1587

deyaaeldeen commented Jul 16, 2025

Uh oh!

Uh oh!

RobertCraigie Jul 28, 2025

Uh oh!

deyaaeldeen Jul 28, 2025

Uh oh!

RobertCraigie Aug 26, 2025

Uh oh!

RobertCraigie Aug 26, 2025

Uh oh!

RobertCraigie Aug 26, 2025

Uh oh!

RobertCraigie Aug 26, 2025

Uh oh!

RobertCraigie Aug 26, 2025

Uh oh!

RobertCraigie Aug 26, 2025

Uh oh!

RobertCraigie Aug 26, 2025

Uh oh!

RobertCraigie Aug 26, 2025

Uh oh!

RobertCraigie Aug 26, 2025

Uh oh!

Uh oh!

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!

Uh oh!