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

How to setup reverse proxy for an SSO session bootstrap

Scheduled Pinned Locked Moved Unsolved
Q&A
2
6
1.1k
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.
  • J
    joseantonio
    last edited by joseantonio 31 Mar 2025, 11:53

    I'm glad it's finally possible to bootstrap an SSO session manually as described here, nice!

    However, as part of the explanation on how to actually achieve it, there's a step that's not explained in detail, which is:

    "FusionAuth requires the access token to be in an Authorization header. Because browsers do not provide a way to set the Authorization header when browsing to a location, you’ll need to add the header using, for example, a reverse proxy.""

    I managed to make it work using nginx as the reverse proxy, I've published a gist to show how.
    Is this approach correct?

    The only thing that seems off is that after redirecting to oauth2/authorize, FusionAuth redirects to the redirect_uri provided, but includes an error about the response_type in the url (SSO session is correctly created though).

    M 1 Reply Last reply 31 Mar 2025, 20:26 Reply Quote 0
    • M
      mark.robustelli @joseantonio
      last edited by 31 Mar 2025, 20:26

      @joseantonio said in How to setup reverse proxy for an SSO session bootstrap:

      here

      Thank you for sharing. What is the error that you are getting about the response_type?

      J 1 Reply Last reply 1 Apr 2025, 07:00 Reply Quote 0
      • J
        joseantonio @mark.robustelli
        last edited by joseantonio 4 Jan 2025, 16:00 1 Apr 2025, 07:00

        @mark-robustelli

        This is the error shown in the url after oauth2/authorize redirects to redirect_uri:

        ?error=invalid_request&error_reason=missing_response_type&error_description=The+request+is+missing+a+required+parameter%3A+response_type
        

        At some point I used a combination of these two params in the oauth2/authorize endpoint to prevent it, is this safe to do or may it come with possible drawbacks?

        • response_type=code
        • response_mode=form_post

        Thanks!

        M 1 Reply Last reply 6 Apr 2025, 19:23 Reply Quote 0
        • M
          mark.robustelli @joseantonio
          last edited by 6 Apr 2025, 19:23

          @joseantonio using the response_type=code should be fine, let me know how it goes.

          J 1 Reply Last reply 7 Apr 2025, 06:46 Reply Quote 0
          • J
            joseantonio @mark.robustelli
            last edited by 7 Apr 2025, 06:46

            @mark-robustelli Thanks! That prevents the error but adds the code to the url, which in my case is not needed, so I'm using response_mode=form_post to hide it. Is that ok?

            M 1 Reply Last reply 7 Apr 2025, 15:12 Reply Quote 0
            • M
              mark.robustelli @joseantonio
              last edited by 7 Apr 2025, 15:12

              @joseantonio When you add the response_type=code. That should be literal 'response_type=code' not response_type={code} where {code} is some secret. Other than that, you can add additional parameters to the query string if needed. As long as you are not passing secrets in the query string you should be ok.

              1 Reply Last reply Reply Quote 0
              4 out of 6
              • First post
                4/6
                Last post