AngularJS OIDC Client静默刷新页面：打包还是单独部署？

Great question—this is a common point of confusion when implementing silent token refresh in Angular SPAs. Let’s break down the two approaches and which one makes sense for your setup:

Option 1: Standalone Page (Separate from index.html) #

This is the most common and recommended approach for silent refresh flows, and here’s why:

• Silent refresh only needs minimal logic: fetch a new refresh token from your auth server, then pass it back to the main app (usually via postMessage). It doesn’t require the full Angular framework, so loading a heavy bundle is unnecessary.
• Faster and more reliable: A standalone page (e.g., silent-refresh.html) loads instantly since it’s just a tiny HTML file with a few lines of vanilla JS. Even if your main Angular app has loading issues, this page will still work to keep tokens refreshed.
• Easy to implement: Place the file in your project’s assets folder or root directory, then configure your build process to copy it directly to the dist folder (without bundling it into Angular’s main chunk). The page’s JS can be as simple as:

  // silent-refresh.html
  window.addEventListener('load', async () => {
    try {
      const response = await fetch('/api/refresh-token', { credentials: 'include' });
      const newTokenData = await response.json();
      window.parent.postMessage(
        { type: 'REFRESH_TOKEN_SUCCESS', token: newTokenData.accessToken },
        window.location.origin
      );
    } catch (err) {
      window.parent.postMessage({ type: 'REFRESH_TOKEN_FAILURE' }, window.location.origin);
    }
    window.close();
  });
  

• Your main Angular app just needs to listen for the message event to handle the new token or failure.

Option 2: Bundled as an Angular Route #

You can include the silent refresh page as a component in your Angular app, tied to a specific route (e.g., /silent-refresh), but this is only useful in specific cases:

• Use this if your refresh logic depends on Angular services (like your AuthService or HTTP interceptors) and you want to reuse existing code.
• Important caveats:
  • Keep the component extremely lightweight. Don’t import unnecessary modules or services—lazy load it if possible, but make sure the chunk is small.
  • Disable any route guards that might block the iframe from accessing the route (e.g., auth guards that redirect unauthenticated users, since the iframe will be running in a context with existing tokens).
  • This approach adds overhead: the iframe will need to load the Angular runtime and bundle before executing the refresh logic, which could introduce a small delay.

Final Recommendation #

Stick with the standalone page for most cases. It’s faster, simpler, and decouples your token refresh logic from the main Angular app—reducing the risk of failures that could break your auth flow.

Just remember to:

• Host the standalone page on the same domain as your Angular app to avoid cross-origin postMessage issues.
• Keep the page’s code minimal and secure (sanitize any incoming messages, validate origins).

内容的提问来源于stack exchange，提问作者hashbytes