<iframe src="https://www.googletagmanager.com/ns.html?id=GTM-M74D8PB" height="0" width="0" style="display:none;visibility:hidden">
Loading
Skip to NavigationSkip to Main Content
System Status
Announcements
Announcements
Search
Search
Select Language
Knowledge Base
Knowledge Articles
Support Videos ↗
Documentation
Product Documentation ↗
Developer Documentation ↗
Product Release Notes ↗
Community
Events & Webinars
Okta Ideas ↗
Resources
Product Hub
Customer Success Hub
Product Release Update
Learning
Okta Learning ↗
Get Support
Open a Case
HomeCommunityForum
0D54z00008LSLMsCAPOkta Classic EngineAdministrationAnswered2025-09-13T09:01:51.000Z2022-11-05T12:59:45.000Z2023-05-04T16:06:05.000Z

gdgc8 (gdgc8) asked a question.

November 5, 2022 at 12:59 PM
SAML Signed Requests failing with error code 400 (SP initiated SSO flow)

I have a SAML2.0 application integration configured.

 

My application is the SP

OKTA is the IDP.

 

With 'SAML Signed Request' disabled in the OKTA application integration configuration, when I initiate a SSO from my app it works fine.

 

Browser is redirected to the OKTA login page .

I enter my credentials and am successfully authenticated.

My browser redirects to the ACS configured for my application.

All good and as expected.

 

However with 'SAML Signed Request' enabled it simply does not work:

When I initiate a SSO from my app:

 

Browser is redirected to the OKTA login page ok.

I enter my credentials and appear to be authenticated but am then redirected to the OKTA application catalogue, not my app.

 

With SAML Tracer enabled in Chrome, I can see that in the fail case no SAML Assertion is generated. After the login redirect I do see :

 

GET

fromURI: /error/400_SAML?stateToken=<the token value was here>

 

But have no idea why I am getting a 400. Correct public certificate has been uploaded via the OKTA admin console.

How do I proceed to determine why a 400 is being received?

 

Thank you

  • 22 answers
  • 5.82K views

  • Paul S. (Okta, Inc.)

    Hello @gdgc8 (gdgc8)​ Thank you for reacting out to our Community!

     

    If the application errors out only when you enable Signed Request, this could mean that the application is not accepting/supporting this feature. You might want to check with the application Support to see if this a feature they support in the SAML assertion.

    If you are using internet explorer you might want to check this article:

    https://support.okta.com/help/s/article/Receiving-400-Bad-Request-when-logging-into-application-only-in-IE?language=en_US

     

    The Okta Community Catalysts Program is now live. Collect online badges when you participate in the Okta Help Center Questions community. Learn more here.

    The October issue of the Okta Community is here and packed with tips on certification, how to earn badges, and new releases. Let us help you stay connected.

    Expand Post

    • NickC.70559 (Customer)

      Hi Paul,

       

      Thank you for the quick reply. Just to provide a bit more context:

       

      We are a vendor application looking to integrate our application sign-on flow on behalf of a mutual client. Our client uses OKTA as an IDP for SSO.

       

      Our application is the SP and is able to successfully complete a SAML SSO login via OKTA whenever 'Validate SAML requests with signature certificate' is disabled. Our application sends a SAML Authn Request which is received and processed by OKTA. The user authenticates and OKTA returns a SAML Assertion which is then successfully processed by our application. User is authenticated and logged into our application. All good and as expected.

       

      However when the 'Validate SAML requests with signature certificate' option is enabled the SSO fails.

       

      1. We are using Chrome Version 107.0.5304.88 .
      2. I have independently verified our public certificate which has been uploaded to the OKTA admin console. The public certificate can be used to decrypt and validate our signed SAML Request without issue. Therefore I do believe the private/public key pair we are using is valid.
      3. I have run a SAML tracer and can see that our SAML Authn Request complies with the SAML Protocol. The signature is not embedded in the body of the message (HTTP-POST model) since we are using the HTTP-Redirect model (&SigAlg, &Signature parameters appended to message).
      4. OKTA receives the signed SAML Authn Request but does not generate a SAML assertion back to our application. Instead, our user is authenticated and redirected to the SAML Application catalogue page. ***Please note: No response SAML Assertion is generated by OKTA***
      5. In the SAML Tracer log I can see this: GET fromURI: /error/400_SAML?stateToken=<token value here> 

       

      Can you please confirm that signed SAML Authentication requests are fully supported in OKTA . Also any clues as to what may be failing here, possible avenues for investigation?

       

      Kind regards

      Expand Post

    • User16709368547312865820 (Customer)

      Hi Paul,

       

      Are you able to confirm this is a bug in the Okta platform, and if so can you give an indication of when it might be addressed?

       

      If not, what do you need to be convinced? 🙂

       

      Regards,

       

      Stu.

      Expand Post

  • NickC.70559 (Customer)

    Hi Stu,

    Unfortunately not. For now I've had to go with the white-listing approach instead. Will post back on this thread should we get it working.

    Regards

  • a0n5s (a0n5s)

    @Nick,could you provide the screenshot of the setting of IDP and SP?

  • nqm9k (nqm9k)

    Same here, for now I just disabled the SAML Signed Request

  • NickO.57179 (Customer)

    Also experiencing this issue. We have disabled the SAML Signed Request for now as well.

    • User16709368547312865820 (Customer)

      It's good that worked for you (and thank you for sharing!) but it is not an option for us as no NameIDPolicy is being included in the SAML AuthnRequest and we do not have control of the contents of the request at that level.

       

      It is an optional element in the SAML 2.0 spec, so Okta should not be failing if it is missing, from http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf section 3.4.1:

       

      <NameIDPolicy> [Optional] Specifies constraints on the name identifier to be used to represent the requested subject. If omitted, then any type of identifier supported by the identity provider for the requested subject can be used, constrained by any relevant deployment-specific policies, with respect to privacy, for example.

      Expand Post
10 of 22
This question is closed.
Loading
SAML Signed Requests failing with error code 400 (SP initiated SSO flow)