Can't change issuer URL for OIDC enterprise connection

[florian.gall]

I wanted to change the issuer URL for an enterprise connection because our customer changed their domain. But it didn’t work - the change got rolled back silently by Auth0 (UI).

There’s two aspects here:

• If it should be possible to change the issuer URL for an OIDC connection
• How Auth0 UI behaves when changing it

To address the second aspect first: I can change the Issuer URL, and when saving, all looks fine. But after some time, the change will revert. Puzzled, I changed the sub-URLs (Issuer, Authorization Endpoint, JWK URL), and noticed that the Authorization Endpoint is the one that keeps reverting back.

There’s two bugs here in my opinion:

1. It looks like changing the Issuer URL has been successful, only for this to silently revert back.
2. There is no indication why the Issuer URL is changing back, i.e. that the Authorization Endpoint is to blame.

I ended up creating a new connection for this to work. No biggie, but I would have appreciated knowing this in advance.

Now, regarding the first aspect, if it should be possible to change the Issuer URL to a new domain - no idea. However, if it’s forbidden by design, please make it clear in the UI!

[marcelina.barycka]

Hey there @florian.gall ,

Thanks for reaching out here in the Community! I’m sorry to hear about the issue with updating the connection.

I’m looking into why, after changing the sub-URLs (Issuer, Authorization Endpoint, JWK URL), the Authorization Endpoint kept reverting back.

My initial track is that, while other Issuer sub-URLs has been updated, the Discovery URL of the OIDC provider (https://.../.well-known/openid-configuration) remained unchanged/unuptated.
Taking that the Discovery URL is a source of the OIDC provider metadata (like the Issuer URL, the Authorization URL, and others - you can check specifically by visiting the Discovery URL of the connection), I would say that this is why other URLs got rolled back.

If it’s possible for you, feel free to verify/test it, or please let me know if there are other questions arising from it

[florian.gall]

Hi @marcelina.barycka ,

Thanks for your input, appreciate the timely help!

I just checked, the old and new Discovery URL (which is present in the Issuer URL field) lead to the correct metadata - the new one doesn’t contain any trace of the old domain. And I did change this URL, that’s the first thing I tried.

Or is there any other field where the Discovery URL has to be changed? In the UI, I only see:

Issuer URL, Issuer, Authorization Endpoint, JWK URL

I just tried again changing all these URLs at once, and to change the Issuer URL first, save, then change the others. The Authorization Endpoint is still reverting.

Am I perhaps missing a configuration option? I have the roles Editor - Connections, Viewer - Config Settings, Viewer - Users.

[marcelina.barycka]

Hi @florian.gall ,

Thank you for sharing!

@florian.gall

Or is there any other field where the Discovery URL has to be changed? In the UI, I only see:

Issuer URL, Issuer, Authorization Endpoint, JWK URL

Alright! I have a bit different view of your configurations (as an internal employee of Okta) and can see an additional field called:
Discovery URL (separate from the Issuer URL one). → This makes me think the UI is unsuitable for updating the existing connection’s Issuer data.

The workaround I would like to offer for the future is using our Management API:

1. GET the connection to retrieve the options object with this call:

You should see there nothing less than the following:

{
   "options": {
       "discovery_url": "https://.../.well-known/openid-configuration",
       "oidc_metadata": {
           "issuer": "https://...",
           "jwks_uri": "https://..../.well-known/jwks.json",
           "token_endpoint": "https://auth...",
           "authorization_endpoint": "https://...",
       },
       "authorization_endpoint": "https://...."
   }
}

2. PATCH the connection with the updated URLs (including the Discovery URL).
   (PATCH will also update fields not included in the call. Thus, the first step is to GET the entire connection JSON).

Feel free to check it out if possible
Apologies for the UI experience. I will review our documentation and if this disclaimer is not included, I will work with our Knowledge Management team to update docs.

[florian.gall]

Ah, yes that would explain it.

Would it be too much to ask for to see this URL also in the UI? Because now I have to talk to one of my engineers and disturb their focus work for such a change instead of doing it myself.

I’ll try your solution though, if that works, at least there is a way without creating a new connection. Many thanks for the help!