Creating an OIDC Connection Fails with "options.issuer is required" Error

Knowledge Articles
1

Overview

When trying to create OIDC connections via CLI or Dashboard, different discovery URLs throw the same error:

Bad Request: “options.issuer” is required

The discovery URL returns the “issuer” field.

Cause

Solution

If there is a working discovery endpoint, create this connection with the Management API POST /api/v2/connections.

The workaround is to paste the entire response payload from the IDP’s discovery endpoint into options.oidc_metadata and do not send options.discovery_url.

“options”: {
“issuer”:“”
“type”:“front_channel”,
“client_id”:“”,
“jwks_uri”:“,
“authorization_endpoint”:”",
“oidc_metadata”:{RESPONSE OBJECT FROM THE DISCOVERY ENDPOINT}
},

Note that there is a feature flag that can be enabled by Okta’s Engineering Team that can be enabled to roll back the new schemas for discovery validations when creating OIDC connections. If this is something desired, please open a case with Okta Support referencing this article in the case description.

1 Like
3

My name is Shane Tomlinson, I am from the Enterprise Federations team which is responsible for supporting the OIDC connection. For anybody that comes across this article hoping to use the Microsoft Common URL with an OIDC connection, please read on.

Using the Microsoft Common URL (https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration) is not something the OIDC connection supports, the {tenantid} within the issuer is indeed considered invalid.

Instead, a waad connection set with the OpenID Connection protocol (waad_protocol: “openid-connect”) should be used. From the manage dashboard UI, this is known as a Microsoft Azure AD connection.

https://auth0.com/docs/authenticate/identity-providers/enterprise-identity-providers/azure-active-directory/v2 provides a high level intro to the connection type and https://auth0.com/docs/authenticate/identity-providers/enterprise-identity-providers/choose-a-connection-type-for-azure-ad provides a detailed comparison of connection types.

Note that there is a feature flag that can be enabled by Okta’s Engineering Team that can be enabled to roll back the new schemas for discovery validations when creating OIDC connections. If this is something desired, please open a case with Okta Support referencing this article in the case description.

Reverting the mentioned feature flag is not something we do and does not fix this case, the issuer is still invalid with the old schemas. Please do not request this feature flag be disabled, it’s in the process of being removed.

To wrap up, when trying to connection to Azure/Entra, use the waad strategy instead. The OIDC connection does not support the Microsoft Common URL for discovery, even with legacy schemas.