How does openid-client v6.0.0 and above handle Origin header

[bchang11]

Hi @panva,

I’ve designed my architecture to store all necessary information for OIDC (e.g., code_verifier, state, etc.) in my server session. For confidentiality, I handle the code exchange for tokens on the server side for both public and confidential clients.

I have a few questions about how openid-client manages the Origin header during this process.

1. Does openid-client automatically attach an Origin header to requests by default?
2. Currently, I’ve been using customFetch to set the Origin header manually for cross-origin requests. However, I’m unsure if client.authorizationCodeGrant() has any built-in capability to manage headers, such as Origin, without relying on customFetch.

const config = await openidClient.discovery(
  server,
  clientId,
  clientSecret,
  undefined,
  {
  [openidClient.customFetch]: createCustomFetch, <<< custom fn uses fetch and explicitly sets Origin header
  }
);

const tokens = await client.authorizationCodeGrant(config, currentUrl, {
  pkceCodeVerifier,
  expectedNonce,
  expectedState,
  idTokenExpected: true
});

Without using the customFetch to explicit set the Origin header and attempting to exchange for Token from my public client, Azure AD responds:

AADSTS9002327: Tokens issued for the 'Single-Page Application' client-type may only be redeemed via cross-origin requests.

I’d appreciate any guidance on whether handling the Origin header this way is necessary or if there are best practices within openid-client for managing headers during token exchanges.

[panva]

Hello @bchang11

How does openid-client v6.0.0 and above handle Origin header

It doesn't. The Origin header behaviour is deferred to the fetch implementation native to the environment it's executed in.

1. no, there's no reason to do anything about the Origin header, in the browser environment it's set automatically and in non-browser environments it's pointless because ...

For confidentiality, I handle the code exchange for tokens on the server side for both public and confidential clients.

... these should then all be confidential clients.

2. no, customFetch gives you all the freedom you need to hack around the bare interoperable minimum that's there

[terrymun]

[panva]

@terrymun I'm so confused, why is there a SPA with a secret... 🤷‍♂️

[panva]

In any case, this indicative of misguided application setup on the Azure platform. If they're enforcing Origin to be present then that's because they expect all requests to be made from a browser, righfully so when the application type is "SPA".

If you actually execute your token exchanges on a server then SPA is the wrong application type to have set up. And so instead of adding an origin header and pretending to be a browser, you should change your application type to a regular web application setting (whatever its called in the azure platform) with a secret made available only to your backend.

[terrymun]

I'll probably dive deeper into that when I've got more time :) I was just setting a POC up with Azure Entra ID and needed it to work. Thanks for the tip!

[terrymun]

Update: I've reconfigured my client to be a web application instead of an SPA, so I no longer run into this issue. Thanks @panva for pointing me in the right direction.