• Home
  • Categories
  • Recent
  • Popular
  • Pricing
  • Contact us
  • Docs
  • Login
FusionAuth
  • Home
  • Categories
  • Recent
  • Popular
  • Pricing
  • Contact us
  • Docs
  • Login

Help/Issue with `state` Parameter in Reverse SSO Flow with FusionAuth

Scheduled Pinned Locked Moved Solved
Q&A
3
8
1.4k
Loading More Posts
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • C
    cristian
    last edited by 30 Jan 2025, 16:39

    Context:

    We are implementing Reverse SSO where FusionAuth acts as the IdP, and we are experiencing an issue with the state parameter when completing authentication with an external OIDC-compliant service (ChainPoint).

    Flow Overview:

    1. MemberSuite initiates the login request using Reverse SSO.
    2. Our SSO Bridge intercepts the request and constructs the authentication URL for FusionAuth, ensuring the state parameter is included.
    3. The user is redirected to FusionAuth for authentication.
    4. Upon successful authentication, FusionAuth redirects the user to ChainPoint.
    5. ChainPoint expects the state parameter for security validation, but it appears to be missing or not returned correctly.

    Authentication URL We Construct:

    We generate the following authentication URL from our SSO Bridge:

    https://auth.example.com/oauth2/authorize?client_id=12345678-1234-1234-1234-123456789abc&response_type=code&response_mode=form_post&redirect_uri=https%3A%2F%2Fchainpoint.example.com%2Flogin%2Fsso%2Fresponse%2F98765432&state=randomgeneratedstate12345
    

    The Problem:

    • We generate the state in our SSO Bridge when constructing the authentication URL.
    • However, when FusionAuth completes authentication and redirects to ChainPoint, the state is not present or correctly returned.
    • Since ChainPoint uses the state for CSRF protection and session validation, the authentication fails.
    • We cannot persist the state in our SSO Bridge because, once redirected to FusionAuth, the SSO Bridge is no longer part of the process.
    • Since FusionAuth is the entity communicating with ChainPoint, we need a way to retain and correctly propagate the state throughout the flow.
    • We cannot modify ChainPoint’s code, nor can we set SameSite=None cookies or manage cross-domain session storage manually.

    Questions & Help Needed:

    1. How can we ensure that FusionAuth retains and correctly returns the state parameter when redirecting to ChainPoint?
    2. Is there a built-in mechanism in FusionAuth to store and return state automatically, or do we need to handle it manually?
    3. Would a Lambda function help ensure that the state is included in the final redirect?

    Any insights or recommendations from the community would be greatly appreciated! I really appreciate any help you can provide.

    Best regards,
    Cristian Acevedo
    Smarterix

    C 1 Reply Last reply 30 Jan 2025, 19:39 Reply Quote 0
    • C
      cristian @cristian
      last edited by 30 Jan 2025, 19:39

      Debug Log from ChainPoint when we try to login in:

      2025-01-28 14:35:35,806 DEBUG LogMessage - Authorize response: code=cbQVpjY5qeODZ1I4251aT46-MOIqG5CgGbMOWBUgVSs&locale=en&userState=Authenticated
      2025-01-28 14:35:36,208 TRACE Trace - ProcessResponseAsync
      2025-01-28 14:35:36,218 ERROR LogMessage - Missing state.
      2025-01-28 14:35:36,235 WARN  ProcessLoginResponse - Unable to login user, error during login token validation: Missing state. ()
      
      
      M 1 Reply Last reply 31 Jan 2025, 15:29 Reply Quote 0
      • M
        mark.robustelli @cristian
        last edited by 31 Jan 2025, 15:29

        @cristian Can you please take a look at https://sptest.iamshowcase.com/instructions#spinit and in particular the Use RelayState to control the color theme section. The are passing a parameter to control the color of the background. This seems to be what you are trying to accomplish. If not, please let me know.

        If you need more details on how to set up the test, please see this blog post.

        1 Reply Last reply Reply Quote 0
        • C
          cristian
          last edited by 3 Feb 2025, 14:50

          Hi Mark! Thanks for your response!

          However, I believe there is some confusion regarding the protocol we are using. The example you shared refers to RelayState, which is specific to SAML, while we are implementing OIDC (OpenID Connect) with FusionAuth as the IdP.

          Our issue is related to the state parameter in OIDC, which is used for CSRF protection and session validation.

          Our main concern is:

          • FusionAuth is receiving the state parameter from our SSO Bridge.
          • When it redirects to the final service (ChainPoint), the state is not present in the response, causing authentication failure.

          Do you know if there is a way to ensure FusionAuth retains and returns the state parameter in the redirect?

          Thanks again for your help!

          M 1 Reply Last reply 3 Feb 2025, 16:47 Reply Quote 0
          • M
            mark.robustelli @cristian
            last edited by 3 Feb 2025, 16:47

            @cristian Apologies for the confusion, I think I conflated two separate issues I was working on. It is my understanding that FusionAuth should maintain the state parameter as explained in this video. If it is not, then there is a bug. I would like to try and set up a simple example to replicate your issue, but that is going to take me a couple of days. I'll let you know what I find.

            BTW, it does not look like you can access the url from a lambda. There may be some things you can do with logging and turning on debugging in FusionAuth, but I will test that out as well. If you get to it before I do, please let me know.

            Thanks.

            C 1 Reply Last reply 3 Feb 2025, 21:16 Reply Quote 0
            • C
              cristian @mark.robustelli
              last edited by 3 Feb 2025, 21:16

              Hi @mark-robustelli,

              Thank you very much for looking into this!

              Fortunately, ChainPoint made some adjustments on their end, and we were finally able to log in successfully using OIDC.

              I really appreciate your willingness to investigate the issue.

              Thanks again for your time and help!

              Best,
              Cristian

              M F 2 Replies Last reply 3 Feb 2025, 21:55 Reply Quote 0
              • C cristian has marked this topic as solved on 3 Feb 2025, 21:16
              • M
                mark.robustelli @cristian
                last edited by 3 Feb 2025, 21:55

                @cristian Glad you got it rolling.

                1 Reply Last reply Reply Quote 0
                • F
                  fuhaustin @cristian
                  last edited by 24 Mar 2025, 21:48

                  Hello @cristian
                  I am kind if facing the same issue here, how did you go about solving it?

                  1 Reply Last reply Reply Quote 0
                  • First post
                    Last post