Multiple audiences with spa 2.x - Requires usage of scope/claims in access tokens to work correctly instead of id token

[AndreasA]

Checklist

• The issue can be reproduced in the auth0-react sample app (or N/A).
• I have looked into the Readme, Examples, and FAQ and have not found a suitable solution or answer.
• I have looked into the API documentation and have not found a suitable solution or answer.
• I have searched the issues and have not found a suitable solution or answer.
• I have searched the Auth0 Community forums and have not found a suitable solution or answer.
• I agree to the terms within the Auth0 Code of Conduct.

Description

Hi,

I already created an issue in the spa.js library auth0/auth0-spa-js#1457

The change to store the id token per client id and not per audience was by design.

The proposed solutions, however, are not that easily doable in combination with auth0-react because there is no easy way to access the access token claims / scopes of the Auth0Provider.

In order to help it should be possible to access the access token data which would be fine in our use case as the scopes etc. are valid for the SPA access token and used to show corresponding data.

However, the id token is replaced on another audience call, which creates issues as they should not have all scopes the SPA has by design, only the ones relevant for that API.

See issue: auth0/auth0-spa-js#1457

Reproduction

1. Use latest auth0-spa-js
2. use latest auth0-react
3. Use SPA with audienceA
4. Use API with audienceB
5. Add scopes/claims to access token (and id token) of audienceA, but not audienceB
6. call getAccessToken... with audienceB manually before calling that API.

The user object of audienceA is lost as it is replaced with audienceB.

Furthermore, as there is no way to access claims/scopes etc. of the access token of audienceA, there is no easy way around this.

See issue: auth0/auth0-spa-js#1457

Additional context

See issue: auth0/auth0-spa-js#1457

auth0-react version

2.9.0

React version

19

Which browsers have you tested in?

Chrome

[gyaneshgouraw-okta]

Hey @AndreasA, thanks for raising this. We've discussed the issue and are still reviewing the architecture around this behaviour. We'll follow up once we have more concrete updates to share.

[yogeshchoudhary147]

Hi @AndreasA,

Thanks for reporting this and referencing the discussion in auth0/auth0-spa-js#1457.

After reviewing your request, we cannot add methods to expose or decode access token claims in auth0-react, as this would promote practices that go against security best practices and OAuth 2.0 specifications.

Why we don't expose access token claims client-side:

1. Access tokens are opaque to the client - They are intended only for resource servers (APIs) to validate and should not be inspected by the client application
2. Authorization decisions should not be made in the browser - Client-side code can be manipulated, so relying on token contents for UI authorization is insecure
3. This violates OAuth 2.0 principles - Access tokens are bearer tokens meant for API access, not for client-side authorization logic

The recommended architectural approach:

The correct solution for handling scopes in multi-audience SPAs is to:

1. Use ID tokens only for basic user profile information (name, email, picture)
2. Request scopes from your API instead of reading them from tokens
3. Store scopes in your application state (React Context, Redux, Zustand, etc.)

Implementation example:

// 1. Create a scopes provider
import { createContext, useContext, useEffect, useState } from 'react';
import { useAuth0 } from '@auth0/auth0-react';

const ScopesContext = createContext<string[]>([]);

export const ScopesProvider = ({ children }) => {
  const [scopes, setScopes] = useState<string[]>([]);
  const { getAccessTokenSilently, isAuthenticated } = useAuth0();

  useEffect(() => {
    const fetchScopes = async () => {
      if (!isAuthenticated) return;

      try {
        // Get access token for your main SPA audience
        const token = await getAccessTokenSilently({
          authorizationParams: { 
            audience: 'audienceA' 
          }
        });

        // Call your API to get user scopes
        const response = await fetch('/api/user/scopes', {
          headers: { 
            Authorization: `Bearer ${token}` 
          }
        });

        const data = await response.json();
        setScopes(data.scopes); // e.g., ['read:data', 'write:data']
      } catch (error) {
        console.error('Failed to fetch scopes:', error);
      }
    };

    fetchScopes();
  }, [getAccessTokenSilently, isAuthenticated]);

  return (
    <ScopesContext.Provider value={scopes}>
      {children}
    </ScopesContext.Provider>
  );
};

export const useScopes = () => useContext(ScopesContext);

// 2. Use in your app
function App() {
  return (
    <Auth0Provider {...auth0Config}>
      <ScopesProvider>
        <YourApp />
      </ScopesProvider>
    </Auth0Provider>
  );
}

// 3. Use scopes in components
function MyComponent() {
  const scopes = useScopes();

  return (
    <>
      {scopes.includes('write:data') && <EditButton />}
      {scopes.includes('delete:data') && <DeleteButton />}
    </>
  );
}

Backend API endpoint to return scopes:

const express = require('express');
const { auth } = require('express-oauth2-jwt-bearer');

const app = express();

// Middleware validates the access token
const checkJwt = auth({
  audience: 'audienceA',
  issuerBaseURL: 'https://your-domain.auth0.com/',
});

app.get('/api/user/scopes', checkJwt, (req, res) => {
  // The validated token payload is in req.auth
  const scopeString = req.auth.payload.scope || ''; // "read:data write:data delete:data"
  
  // Convert space-delimited string to array
  const scopes = scopeString.split(' ').filter(Boolean);
  
  res.json({ 
    scopes // ["read:data", "write:data", "delete:data"]
  });
});

Why this approach solves your issue:

Your problem: When you call getAccessTokenSilently for audienceB, the ID token gets replaced, losing the scopes from audienceA.

The solution: Don't rely on tokens at all for UI state. Instead:

1. On app load, fetch scopes from your API (using audienceA token)
2. The API validates the access token and extracts the scope claim
3. Store these scopes in React state
4. When you later request a token for audienceB, your UI state remains unchanged because it's not tied to tokens
5. Your scopes persist regardless of which audience's token is currently cached

Why this approach is superior:

✅ Solves the token replacement issue - UI state is independent of cached tokens
✅ More secure - Scope validation happens server-side where it can't be tampered with
✅ More flexible - Scopes can be refreshed without re-authentication
✅ More scalable - Works seamlessly with any number of audiences/APIs
✅ Clearer architecture - Tokens authenticate API requests, application state controls UI

Conclusion:

The behavior you're experiencing with ID tokens being replaced in v2 is working as designed and follows the OpenID Connect specification.

The solution is not to expose access token scopes client-side by decoding JWTs, but to architect your application to fetch scope information from your API and manage it in application state.

We'll update our documentation to better explain this pattern for multi-audience SPAs.

Closing this issue as the recommended solution doesn't require changes to auth0-react.

Please feel free to follow up if you have questions about implementing this approach.