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
When using a authorization server the URL generation code truncates off the oauth2/${authorizationServerId} resulting in a 404 error when attempting to hit the openid-configuration URL. For the non-custom authorization server use case, the code works fine.
What are the steps to reproduce this issue?
Setup a custom authorization server in Okta for OpenID Connect
Set the SOCIAL_AUTH_OKTA_OPENIDCONNECT_API_URL variable to your custom server URL
Attempt to authenticate through the app.
Any logs, error output, etc?
I'm using this module through https://github.com/netbox-community/netbox which is currently pinned to version 4.1.0. The behavior I describe in this ticket is actually the opposite, custom-auth servers work and non-custom auth servers break. I wrote this issued based on this commit which sets up the behavior described in this issue.
The text was updated successfully, but these errors were encountered:
Expected behaviour
When using a custom authorization server, with OktaOpenIdConnect, the proper openid-configuration URL should be generated.
Actual behaviour
Okta OpenID Connect has two different URLs for the openid-configuration API.
https://${yourOktaDomain}/.well-known/openid-configuration
https://${yourOktaDomain}/oauth2/${authorizationServerId}/.well-known/openid-configuration
When using a authorization server the URL generation code truncates off the
oauth2/${authorizationServerId}
resulting in a404
error when attempting to hit the openid-configuration URL. For the non-custom authorization server use case, the code works fine.What are the steps to reproduce this issue?
SOCIAL_AUTH_OKTA_OPENIDCONNECT_API_URL
variable to your custom server URLAny logs, error output, etc?
I'm using this module through https://github.com/netbox-community/netbox which is currently pinned to version 4.1.0. The behavior I describe in this ticket is actually the opposite, custom-auth servers work and non-custom auth servers break. I wrote this issued based on this commit which sets up the behavior described in this issue.
The text was updated successfully, but these errors were encountered: