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:
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.
The first URL will be present for all Orgs, as it is the metadata endpoint for the built-in Org Authorization Server that is available for all orgs for OIDC use cases.
The second URL refers to the Custom Authorization Server called Default that is only available for certain licenses. Your test orgs, likely a Developer org or an Okta Preview org, can have this paid feature enabled for them without affecting your license. In production orgs, you must be have a SKU or feature in your license that grants you the ability to use the default server. This URL is actually the same as the 2rd one, because the “Default” authorization server’s ID is “default,” while any new custom authorization servers you create will have an id that will be used in place of “default.”
If the org being used has the ability to use custom authorization servers, they likely have the default server, but as this server is only generated for them when the API AM feature is enabled so there is a chance they may have deleted this server at some point. In which case, another custom authorization server would need to be specified.
In most OIDC use cases, where you simply need ID tokens with information about the logged in user, using the Org Authorization Server is recommended as, like I said, it is available for all Okta tenants. If you are instead looking to support an OAuth use case, where a resource server is protected by OAuth tokens generated by Okta, a custom authorization must be used, which as I mentioned requires an adequate license, and it will most likely be best to have your users provide the issuer uri for you instead of guessing that they have the default server available or having to worry about any customizations they may have made to the default server that could cause problems in your application.
Based on what you’ve written, I think you are right that we should just use the Org auth server. We use OpenID Connect for authentication and to get basic user info. For this we create a Web app. We also create a Service app in order to check group membership. I think this already uses the Org auth server.