You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We currently use various auth providers for our auth servers across the company. Originally these webapps were built solely using Okta auth provider auth servers, so using Okta Auth JS and Okta React was straight-forward. In an effort to ease the transition towards this a new hybrid auth server environment we were hoping to let the web apps continue to use their existing OAuth library to authenticate with these other auth servers as well. So far this works great, except for one caveat, Okta Auth servers seem to have a unique header that allows a specific custom header in CORS request: X-Okta-User-Agent-Extended.
This of course, is not whitelisted in the other auth servers...and to my knowledge isn't something that can be configured. Given this header is primarily used for debugging purposes to easily view the okta versions in a HAR file or screenshots, I think it would be reasonable to propose that this custom header is set as a default, but there is a configuration option to disable it when a need arises to integrate with an auth server from another auth provider.
Reproduction Steps?
Create a non-Okta Auth Server and use the Okta Auth JS config to login
Describe the bug
We currently use various auth providers for our auth servers across the company. Originally these webapps were built solely using Okta auth provider auth servers, so using Okta Auth JS and Okta React was straight-forward. In an effort to ease the transition towards this a new hybrid auth server environment we were hoping to let the web apps continue to use their existing OAuth library to authenticate with these other auth servers as well. So far this works great, except for one caveat, Okta Auth servers seem to have a unique header that allows a specific custom header in CORS request: X-Okta-User-Agent-Extended.
This of course, is not whitelisted in the other auth servers...and to my knowledge isn't something that can be configured. Given this header is primarily used for debugging purposes to easily view the okta versions in a HAR file or screenshots, I think it would be reasonable to propose that this custom header is set as a default, but there is a configuration option to disable it when a need arises to integrate with an auth server from another auth provider.
Reproduction Steps?
Create a non-Okta Auth Server and use the Okta Auth JS config to login
Notice you will get a CORS error in the console due the custom
X-Okta-User-Agent-Extended
header.SDK Versions
All versions use a custom header
Additional Information?
No response
The text was updated successfully, but these errors were encountered: