I’m looking for clarification on the purpose and proper usage of the three variations of URL for retrieving OIDC configuration / endpoints. The three variations I have found are:
https://{oktadomain}/.well-known/openid-configuration
https://{oktadomain}/oauth2/default/.well-known/openid-configuration
https://{oktadomain}/oauth2/{authServerId}/.well-known/openid-configuration
In a test domain I can use the first two variants and get (slightly different, as expected) results. This test domain does not have any custom auth servers set up (whatever that means), so I have no ID to try the third variant.
On a “real” domain created and managed by a different organization, when they try the middle variant (with “default” as the auth server ID), the result is a 401 error. The first variant (with no auth server ID at all) returns what looks like a valid response.
So my questions are:
Will the first variant (no oauth2, no auth server ID) work in all cases, and will the resulting endpoints also be valid?
Or is one of the second two variants (with oauth2/asid) required in order to get working endpoints?
Under what conditions should any of the three variants be used? Is there one static URL (modulo the okta domain) that will work in all cases, or do I also need to ask the person managing their okta domain to provide an auth server ID?
Our current workflow requests the okta domain and an API token, and then uses the API to create an App with various settings. This succeeds without us knowing or asking the user for an auth server ID. Can we determine the auth server ID from the response when creating the app (I don’t see it in the result) ?
Our goal is to automate as much as possible, so the less information we have to ask for the better. Often the person needing the Okta app does not have access to the okta domain dashboard, so must go through another person to get information that they don’t understand (or need or want to understand) in the first place.
Thanks for any guidance on this topic!