How to setup reverse proxy for an SSO session bootstrap
-
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).
-
@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?
-
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_typeAt 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!
-
@joseantonio using the response_type=code should be fine, let me know how it goes.
-
@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?
-
@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.
