feat: call-others-api, Vercel AI + React SPA

[priley86]

Description

This introduces a Vercel AI + React SPA tab to the "Call Other's APIs on User's Behalf" page.

see: auth0-lab/auth0-ai-js#254

References

https://auth0team.atlassian.net/browse/AIDX-97

Testing

Describe how this can be tested by reviewers. Be specific about anything not tested and reasons why. If this library has unit and/or integration testing, tests should be added for new functionality and existing tests should complete without errors.

Please include any manual steps for testing end-to-end or functionality not covered by unit/integration tests.

Also include details of the environment this PR was developed in (language/platform/browser version).

• This change adds test coverage for new/changed/fixed functionality

Checklist

• I have added documentation for new/changed functionality in this PR or in auth0.com/docs
• All active GitHub checks for tests, formatting, and security are passing
• The correct base branch is being used, if not the default branch

[deepu105]

Can we follow the structure and patterns in other quickstarts like the vercel+next.js one for example

[priley86]

thanks for review @deepu105 🙇 , will reflect some updates shortly.

[priley86]

tried to address all in:
fa07281

https://auth0-genai-calling-apis-react-hono-ai-sdk.mintlify.app/get-started/call-others-apis-on-users-behalf#vercel-ai-%2B-react-spa

cc: @deepu105

[deepu105]

Looks good, some minor suggestions and questions

[deepu105]

One issue with having this in the SDK repo example is that the example might change more frequently compared to the quickstart, so unless the same team is maintaining and ensuring compatibility, this will end up breaking the quickstart. For other quickstart we have the sample and starters hosted in auth0-samples/auth0-ai-samples repo

[priley86]

cc: @pmalouin. I'm not sure here.

We are a bit strapped for time w/ several evolving SDK updates now, and my thought is that it is known these SDKs will be changing in the future. Having those changes more local (closer to the core source) will likely make them easier to update. But you are right that, downside is some drift w/ additional quickstarts maintained downstream. Upside is more timely examples which more accurately reflect current platform. Something to consider more in the long-term as we start to consider Core SDKs sourced from auth0/auth0-auth-js as well.

[deepu105]

we can figure this out later

[deepu105]

I'm not familiar with Hono so ignore if its a stupid question. Usually, we get this via auth0.getSession() from the SDK right, is that not preferred here? feels a bit weird setting token on global context

[priley86]

agreed here & raised it as well - i think we are planning to expose as a common middleware from auth0/auth0-hono or auth0/auth0-auth-js which makes this cleaner in the future.

Short answer -> we do not have a great solution in place in the core sdk's for this yet, and we will likely prefer the common auth0 libraries over using something like hono/jwk for performing the jwk validation. A few things have already been proposed for MCP servers and others, but nothing has been defined yet.

For now, i think we may be able to improve upon this and resemble something closer to the long term w/:

// Middleware to set auth context
export const setAuthContext = (authContext: AuthContext) => {
  return async (c: Context, next: () => Promise<void>) => {
    c.set('authContext', authContext);
    await next();
  };
};

// Updated tool wrapper that accepts context
export const createGoogleCalendarTool = (c: Context): ToolWrapper => {
  const authContext = c.get('authContext') as AuthContext;
  
  if (!authContext?.accessToken) {
    throw new Error("Access token not available in auth context");
  }

  return auth0AI.withTokenForConnection({
    accessToken: async () => authContext.accessToken,
    subjectTokenType: SUBJECT_TOKEN_TYPES.SUBJECT_TYPE_ACCESS_TOKEN,
    connection: process.env.GOOGLE_CONNECTION_NAME || "google-oauth2",
    scopes: [
      "https://www.googleapis.com/auth/calendar",
      "https://www.googleapis.com/auth/calendar.events.readonly",
    ],
  });
};

As we will be doing something similar to retrieve this token via the SPA's Auth header rather than server-side session (like in Next.js).

I can try to update this today and circle back here. The shape of the Core SDK has changed as well, but that is well outside of the current scope, and impacts many other things.

[priley86]

opened:
auth0-lab/auth0-ai-js#260

any concerns w/ this revised approach for now? Will go ahead and reflect here for now as well...

[deepu105]

Looks better

[priley86]

seeing some Vale spell check errors which makes me think this has not been fully configured for this project quite yet, but the action is enabled.
https://github.com/auth0/docs-v2/runs/48343533939

Likely a more comprehensive change to review all spelling warnings and ignores, so leaving this alone for now. Happy to follow a convention once established, but for now disabling those.

[deepu105]

ya I was starting to wonder if its useful as well.

[deepu105]

Some batch commitable suggestions