AdditionalHeaders not applied on authorize request

[sarahmarkless]

Issue

I am tyring to set up an authorize call, using serviceConfiguration to define authorization and token endpoints. I additionally want to send a header, but I've noticed that additionalHeaders only applies when on the first call to ./well-known/openid-configuration, and not to the subsequent call to /authorize

setup:

const config = {
      issuer:
        authorizeURL,
      additionalHeaders: { key: value },
      customHeaders: { authorize: { key: value } },
     ...otherProps
    };

Is there any workaround for this to send a header in the authorization call?

---

Environment

• Platform that you're experiencing the issue on: both
• Your react-native Version: e.g. 0.74.5
• Your react-native-app-auth Version: e.g. 8.0.0
• Are you using Expo? No

[carbonrobot]

The additionalHeaders property applies to iOS devices only, and is passed to the AppAuth-iOS library directly. That library in turn uses it for authorization and token requests. The customHeaders property is similar, but for Android.

Could you tell me more about what headers you are having problems with and any error messages? What is the OAuth2 provider you are connecting to? Are those headers on the accept list for that provider?

[sirmong]

same issue here

[sarahmarkless]

I am trying to set a Cookie header in order to set a custom cookie in the authorize request to set consent information to the sign in web page.

When adding this to both additionalHeaders and customerHeaders
additionalHeaders: {
'Cookie': cookieName=cookieValue,
},
customHeaders: {
authorize: { 'Cookie': cookieName=cookieValue },
},

From inspecting the network requests for both Android and iOS, I can see this Set-Cookie header being applied on call to ./well-known/openid-configuration, but not to the subsequent call to /authorize.

[sarahmarkless]

Having investigated further, it is applying on the /tokens endpoint, it is just the /authorize endpoint it does not apply to. This is the only call that comes from the webview rather than the app itself, so maybe further changes are needed to pass the header into the /authorize call?