Error loading discovery document: endpoint belongs to different authority

Hi everyone.

I’m trying to use the IdentityModel (3.10.10) nuget package in a C# application in order to do a Client Credentials authorization flow. The very first step is to get the discovery endpoint information, which looks like this:

var disco = await DiscoveryClient.GetAsync(ConfigurationManager.AppSettings["OktaDomain"]+ "/oauth2/default");

This currently returns an error stating: “Endpoint belongs to different authority: https://*****.oktapreview.com/oauth2/v1/clients”

I went and loaded the discovery document in a browser and found the following:

{
    issuer: "https://****.oktapreview.com/oauth2/default",
    authorization_endpoint: "https://****.oktapreview.com/oauth2/default/v1/authorize",
    token_endpoint: "https://****.oktapreview.com/oauth2/default/v1/token",
    userinfo_endpoint: "https://****.oktapreview.com/oauth2/default/v1/userinfo",
    registration_endpoint: "https://****.oktapreview.com/oauth2/v1/clients",
    jwks_uri: "https://****.oktapreview.com/oauth2/default/v1/keys",
    response_types_supported: [
            "code",
            "id_token",
            ... and so on

Lo and behold, the registration_endpoint is not referring to our default authorization server. This appears to be a bug, or perhaps I’m missing something important. I’d rather not disable discovery document validation to make this work. Any ideas as to what I may be doing wrong?

I’m having the same problem. Did you ever resolve this or did you just disable validation?

Came across the same problem with IdentityModel.
@wej68 in case if you are still interested, you can pass a list of endpoint names to ignore to DiscoveryPolicy that is a part of DiscoveryDocumentRequest.

It should look like
var discoveryRequest = new DiscoveryDocumentRequest()
{
Address = authorityUrl,
Policy = new DiscoveryPolicy
{
EndpointValidationExcludeList = new List { “registration_endpoint” },
}
};

And then you pass this discovery request to the extension method:
var disco = await client.GetDiscoveryDocumentAsync(discoveryRequest);

Hope it helps

2 Likes

@wej68, I just disabled validation

@Hellaren thanks! That is at least a step in the right direction; I’ll implement that for our next round of testing. Hopefully someone from Okta will chime in to verify if their discovery document is configured this way on purpose.

1 Like

I’m experiencing this same problem. I was hoping someone from Okta would chime. I’m sure it’s different for a reason, but I’d like to understand why it is the way it is.

In Okta, client registration occurs at the Org level, not the Authorization Server level. Apps are global to the Org and can be used for multiple Authorization Servers given correct policy config, and you cannot register a client for only one Authorization Server

This is why the path in metadata is not specific to the authorization server that the discovery request was for.

2 Likes

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.