• Public

Single Sign-On

Skip Feed

  1. MarkM.32035 (Customer)

    October 7, 2026 at 7:37 PM

    I have newly joined my organization and this is my first time working with Okta SSO, so I apologize if my terminology is incorrect or will have slow responses as I was given a research task that I'm hoping for some insight on.

     

    It sounds like several years ago someone with my organization set up a branded instance of Okta thinking it was a staging environment but it ended up being production. The unbranded URL is considered the default for the organization at this time. As a result of this dual environment configuration it was discovered that when some of the applications are being accessed from the unbranded instance, if URLs are using the Branded instance users get a second SSO prompt because of how the browser token is bound to the unbranded URL and has to be regenerated again for the branded one. Again, I'm not yet that familiar with the process.

     

    Is there a way short of checking every application manually to find the links and SAML metadata to identify which of these apps may be experiencing this issue? I'm hoping for some sort of report or something I can export, but am afraid it will be a manual check of every app.

    Expand Post
    • 1 comment
    • 13 views

    • Mihai N. (Okta, Inc.)

      Hi @MarkM.32035 (Customer)​ , Thank you for reaching out to the Okta Community! 

       

      Okta does not expose a "which domain is this app using" field in bulk reports. The domain binding lives in the SAML metadata URL and issuer configuration, which must be read from each app's Sign-On settings. However, using the API to list all apps first will at least give you a complete inventory to work through systematically, rather than hunting through the UI blindly.

       

      There is a widely used, community-built browser extension called Rockstar (available in the Chrome Web Store) that is considered a must-have for Okta Administrators.

      1. Install the Rockstar extension and log into your Okta Admin Console.
      2. An overlay menu will appear on your screen. Go to Directory > Apps in Okta.
      3. In the Rockstar menu, click Export Apps.
      4. This will generate a CSV file of your applications. While the CSV might not contain every deep SAML configuration URL, it contains the app metadata.
      5. Alternatively, you can use Rockstar to easily click "Export API" while on the Apps page, which will dump the raw JSON of all your apps. You can then open that file in Notepad or some other text editor software and use CTRL+F to search for your branded URL (e.g., sso.company.com) to quickly identify the apps you are looking for.

       

      If that does not help, please open a case to work with the Okta Support team on this. 

       

      Regards.

      --

      Help others in the community by liking or hitting Select as Best if this response helped you.

      Collect them all. Learn a new skill and earn a new Okta Learning badge.

      Just released: More Okta Community badges just added

      Expand Post

    • Paul S. (Okta, Inc.)

      Hello @avshch (BCRC)​ Thank you for posting on our Community page!

       

      Single use native to web exchange refers to a specific configuration section within Okta Identity Engine's Native to Web SSO feature. It allows an administrator to define an allowlist of native or OpenID Connect (OIDC) applications that are permitted to exchange their existing authentication tokens for a single-use interclient token.

      This token seamlessly opens a browser session in a target web application (SAML or OIDC) without requiring the user to undergo a fresh, interactive sign-on process.

      Practical Use Cases

      • Seamless Native-to-Web Handoffs: If a user is securely logged into a native mobile or desktop app and taps a link that directs them to a standalone web browser, this exchange silently authenticates the web session. The user bypasses the friction of a secondary login screen.
      • Embedded Secure Web Views: When a native app needs to render a complex web interface (such as a billing portal, a customer support system, or an e-commerce checkout) via an in-app browser, the exchange allows the web view to instantly inherit the user's authenticated state from the native host app.
      • Protocol Bridging (OIDC to SAML): Organizations can use this to bridge modern and legacy environments. An external OIDC application can securely request a token to transition a user into an internal, SAML-based web application.
      • Streamlined Admin Workflows: An internal custom tool or dashboard (OIDC) can utilize this exchange to securely transition an authenticated administrator directly into privileged target web portals, such as the Okta Admin Console or Okta Workflows.

       

      Please find our doc below:

      https://developer.okta.com/docs/guides/native-to-web-sso/main/

       

      Thank you for reaching out to our Community and have a great day!

      --

      Help others in the community by liking or hitting Select as Best if this response helped you.

      Expand Post

  3. MehdiS.71478 (Customer)

    July 3, 2026 at 7:51 PM

    Hello,

    We're experiencing an issue where Okta ThreatInsight is classifying the public IP 196.64.7.66 as an Anonymizer, causing legitimate authentication attempts to be blocked.

    This IP belongs to IAM (Maroc Telecom), one of the largest ISPs in Morocco, and is a public residential/business IP—not a VPN or anonymization service. You can verify the IP ownership here:

    https://ipctl.io/ip/196.64.7.66

    Since a large number of our remote users connect through IAM, we're concerned this may not be limited to a single IP. If other IAM IP ranges are also being misclassified, it could impact many legitimate users.

    Has anyone encountered a similar issue? Is there a process for Okta to review or correct the reputation/classification of an ISP's IP ranges, or to escalate a potential false positive in ThreatInsight?

    Any guidance would be greatly appreciated.

    Expand Post
    • 1 comment
    • 70 views

    • Mihai N. (Okta, Inc.)

      Hi @TimothyH.00153 (Customer)​ , Thank you for reaching out to the Okta Community! 

       

      If only one user has the problem, it's most likely an environmental issue.  

      Check to see if this happens via incognito or other browser. See if clear cache/cookies helps. 

      See if they perhaps use some wrongfully copy/pasted URL that might have a redirect/fromURL in it.

      If that does not help, and if it's a SAML app, try checking with SAML Tracer to see what happens during authentication. 

      I'm not expecting the Okta System Logs to show anything(but you can check them), as they don't track a successful authentication on the third-party app side (that would be for the app side to confirm), so the syslogs would just show "successful" once the user clicks on the app icon in the Okta Dashboard and is sent to the app website.  

       

       

      Regards.

      --

      Help others in the community by liking or hitting Select as Best if this response helped you.

      Collect them all. Learn a new skill and earn a new Okta Learning badge.

      Just released: More Okta Community badges just added

      Expand Post

  5. HyunK.48263 (Customer)

    Edited January 12, 2026 at 4:13 PM

    Subject: Set NameID to EmailAddress while logging in with Unique ID

     

    Issue: Our system requires the NameID attribute to be populated with the user’s email address. However, users must authenticate using their Unique ID.

     

    Question: How can we configure the Okta to use the Unique ID for login but return the email address in the NameID field?

     

    ========== MY SAML EXAMPLE RECEIVING FROM OKTA =======

    NOTE: See in bold, we need their email address and still allow the user to login using their Unique Id.

    ...

    ...

    ...

        <saml2:Subject xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">

          <saml2:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"><strong>123456789</strong></saml2:NameID>

          <saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">

            <saml2:SubjectConfirmationData InResponseTo="123"

              NotOnOrAfter="2026-01-06T19:37:26.484Z"

              Recipient="https://authn.test.com/sso/saml/acs/test" />

          </saml2:SubjectConfirmation>

        </saml2:Subject>

        <saml2:Conditions NotBefore="2026-01-06T19:27:26.484Z"

          NotOnOrAfter="2026-01-06T19:37:26.484Z"

          xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">

          <saml2:AudienceRestriction>

            <saml2:Audience>urn:test:sso:saml:test</saml2:Audience>

          </saml2:AudienceRestriction>

        </saml2:Conditions>

        <saml2:AuthnStatement AuthnInstant="2026-01-06T13:26:48.304Z"

          SessionIndex="asd"

          xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">

          <saml2:AuthnContext>

            <saml2:AuthnContextClassRef>

              urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml2:AuthnContextClassRef>

          </saml2:AuthnContext>

        </saml2:AuthnStatement>

      </saml2:Assertion>

    </saml2p:Response>

    Expand Post
    • 6 comments
    • 128 views

    • Paul S. (Okta, Inc.)

      Hello @HyunK.48263 (Customer)​ Thank you for posting on our Community page!

       

      If I understood the question correctly, you are looking to use Unique ID for Okta authentication and to use Email attribute for an application authentication.

      If the above is correct, then this can be done, as the Okta login and the app login does not have to be the same value. For the app login you can setup the desired value from the App Sign on Page and you can set it up as what ever value you want.

       

      Thank you for reaching out to our Community and have a great day!

      --

      Help others in the community by liking or hitting Select as Best if this response helped you.

      Join the discussion for our Ask Me Anything on January 20, 2026: Adoption of Stronger Authentication MFA. Ask our expert questions. 

      Expand Post

  6. MorganH.19528 (Customer)

    December 5, 2025 at 2:26 PM

    Subject: Request for MFA Reset / Support Contact Needed

    Hi everyone,

    Could you please assist us by providing the contact details of your support team?

    We are still experiencing an issue with the Multi-Factor Authentication (MFA) and are currently unable to reach support because our access is completely blocked. We have our username and password, but no longer have access to the MFA device.

    Additionally, the person who originally set up the MFA no longer has access to the app or the key used to authenticate with Auth0. As a result, we cannot recover or validate the MFA on our side.

    Would it be possible to reset or reconfigure our MFA setup?

    Thank you in advance for your assistance.

    Best regards,

    Morgan Hanin

    Expand Post
    • 1 comment
    • 99 views

    • Mihai N. (Okta, Inc.)

      Hi @MorganH.19528 (Customer)​ , Thank you for reaching out to the Okta Community! 

       

      Please note that free trial/developer/integrator accounts are only recoverable via self-service provided that you have configured the appropriate policies and backup accounts.  You can also review the recovery process mentioned in this article. 

      We strongly recommend configuring test users and groups to be used in conjunction with enrollment/authentication policies that would not apply to your admin accounts.  

       

      If you have a paid account with us please email us at community@okta.com from the address associated with the SuperAdmin and provide the Okta Org URL (ex. <companyName>.okta.com) and we can look into potentially opening a support ticket on your behalf. 

       

      If no paid developer or production account is available,  the only option left is to sign up for a new free trial or integrator account with a new email and leverage those for testing. 

      Beyond that, engaging our Okta Sales team to discuss the matter of acquiring Okta Support services would be the only option as it is unfortunately completely outside of the Okta Community Team's scope. 

       

       

       

      Regards.

      --

      Help others in the community by liking or hitting Select as Best if this response helped you.

      Collect them all. Learn a new skill and earn a new Okta Learning badge.

      Just released: More Okta Community badges just added

      Expand Post

  7. JamesJ.02696 (Customer)

    September 4, 2025 at 4:07 PM

    Hi,

     

    This is my first time posting so I'm not sure if this is the proper method to ask a question. I have a customer who wants to use Okta as an IdP with our software, and they want to use an Okta Tile.

     

    Our old SSO would take the URL and change ..../Saml2/Acs to /RfsMenu.aspx and then the Okta Tile would work.

     

    Our new SSO (which we call Auth Server) does not work with this solution. I know the new solution we use is different on the backend, but I'm not sure how to change how we set up okta to make the Okta Tiles work.

     

    Does anyone else have any ideas? Do I need to provide additional information?

    Expand Post
    • 1 comment
    • 103 views

    • User17157611498146715886 (Customer Support Online Community and Social Care)

      Hello @JamesJ.02696 (Customer)​ , thank you for contacting Okta Community.

       

      Is your app part of the OIN (Okta Integrated Network)? In other words, is it available in the App Catalog? If so, you may want to check in with our dedicated team at oin@okta.com.

       

      If it is not an OIN app, but a custom SAML app integration, I recommend that you open a Support ticket* (Customer Support Account ID number required) so one of our engineers can analyze it and provide in-depth troubleshooting. You could also provide more details in a ticket that shouldn’t be given here, as this is a public space.

      *Please note that opening a support ticket is a feature available only to paid accounts. If you do not have a paid account, but are interested in upgrading, you can contact our Sales team. 

       

      Regards. 

      --

      Help others in the community by liking or hitting Select as Best if this response helped you.

      Just released: More Okta Community badges just added

      Expand Post

  8. AdamF.07802 (Customer)

    August 12, 2025 at 3:39 PM

    We have created an OpenID Connect app that uses Okta for SSO, but I'm confused about something. It seems to only be allowing Okta users from our org to sign in. We would like to allow any user with an Okta account to sign in, without having to make a prior arrangement with their org. Our app seems to be in Federation Broker Mode, which seems like it should allow this, but it is not working (when we try to log in with an account from another Okta org, we get a generic "unable to sign in" from Okta. The url we are redirecting to is tied to our organization - could that be the problem? What else might be wrong here? It should be possible to have it work this way, correct?

    • 2 comments
    • 105 views

End of Feed
End of Feed
8 Chatter Feed Items

Group Details

Details