This article addresses instances where users experience repeated reauthentication prompts when attempting to access applications configured with SAML, particularly after a custom domain has been enabled for the Okta organization.

• Custom Domain
• Security Assertion Markup Language (SAML)
• Single Sign-On (SSO)

This reauthentication issue primarily occurs because the Service Provider (SP) is still configured with the SAML metadata or endpoint URLs that point to the original Okta default domain (orgname.okta.com). When Okta, acting as the Identity Provider (IdP), redirects the user or sends a SAML assertion from the new custom domain (login.companyname.com), the Service Provider does not recognize or trust the new domain, leading to an authentication failure or reauthentication request.

To resolve this, the Service Provider's (SP) SAML configuration must be updated with the current and correct metadata from Okta. The approach for obtaining this metadata depends on the Okta custom domain setup:

• Scenario 1: Single Custom Domain Configured for the Okta Org

  • Obtain the updated SAML metadata. Typically, it is possible to use the Metadata URL provided by Okta (which will now reflect the custom domain https://login.companyname.com/app/{appId}/sso/saml/metadata) to download the XML file directly.

   

• Scenario 2: Multiple Custom Domains Configured for the Okta Org (Okta Brands/Multibrand)

  • When multiple custom domains are active, the metadata URL displayed in the Okta Admin Console will still show the default Okta subdomain, https://orgname.okta.com/app/{appId}/sso/saml/metadata. To ensure that the metadata is received from the desired custom domain, it is necessary to manually construct the metadata URL using the chosen custom domain. For example, if the custom domain is login.companyname.com, and the app ID is 0oa123abc, the metadata URL would be https://login.companyname.com/app/0oa123abc/sso/saml/metadata.

   

• Final Step (Applies to Both Scenarios): Update the Service Provider (SP) Configuration

  • This is the critical step to resolve reauthentication issues. The new metadata information must be provided to the Service Provider.
  • Depending on the SP, this may involve:
    • Uploading the newly downloaded SAML metadata XML file (whose content reflects the chosen custom domain) to the SP.
    • Manually updating the following fields in the Service Provider's SAML configuration to match the values found within the updated Okta metadata:
      • Identity Provider Issuer / Entity ID: (Must match the Okta Custom Domain Issuer, for example, https://login.companyname.com/)
      • Identity Provider Single Sign-On URL / SSO Endpoint: (Must match the Okta Custom Domain SSO URL, for example, https://login.companyname.com/app/.../sso/saml)
      • X.509 Certificate: Ensure the SP has the correct, current signing certificate used by Okta's Custom Domain.