SAML IDP Initiated Login


(Reilly Brogan) #1

I’m not seeing this in the SAML plugin documentation, how do we initiate login from the IDP -> Sonarqube? If we set the SSO URL as we receive the error message:

You're not authorized to access this page. Please contact the administrator.

Reason: Cookie 'OAUTHSTATE' is missing

when we try to initiate login from our IDP (in our case Okta). Is there a different URL that we should be trying instead, or is this functionality not currently present in the SAML plugin? Logging in from the Sonarqube login page works so we know that everything else is configured correctly. Sonarqube is the only application we have that we haven’t been able to get IDP initiated login working from.

(Alain O'Dea) #2

UPDATE: see below. Firefox user error on my part.

I get this issue as well.

I wind up having to manually visit in order to use SonarQube after a SAML login. It doesn’t always happen, but when it does it’s very confusing for my users.

(Alain O'Dea) #3

UPDATE: see below. Firefox user error on my part.

I just got this to occur in an SP initiated flow from

After SAML login I’m redirected to‘OAUTHSTATE’+is+missing

If I manually visit after the login has worked and I can see private projects again.

It only appears to happen after inactivity (maybe session timeout).

If I explicitly log out and then visit, it also happens consistently.

If I explicitly log out, then visit, then click Log In with SAML it logs in without issues.

(Julien Lancelot) #5


Sorry for the late replay, it seems that Okta is not returning the value sent into the parameter RelayState when initiating SSO process.
Would you be able to verify if the URL sent from Okta to SonarQube contains or not this parameter ?


(Alain O'Dea) #6

This was a Firefox thing for me.

I dug a little deeper, and it turned out to be a really odd interaction with Container tabs in Firefox. I was opening in a non-Container tab, but my SAML IdP domain was set to always open in my Work Container. As a result it lost the OAUTH_STATE cookie set by /sessions/init/saml after it went to load the IdP.

The flow is like this:

  1. (no Container) visit
  2. (no Container) load response (including OAUTHSTATE cookie) and redirect to IdP URL with SAMLRequest
  3. (Work Container) IdP URL is set to always open in the Work Container so browser loads it here
  4. (Work Container) load response and redirect to (with no OAUTHSTATE cookie)
  5. (Work Container) redirect to OAUTHSTATE cookie missing error page

The fix is to set the domain and the IdP domain to open in the same Container (in my case, Work). It also works if neither Sonar nor the IdP domain are set to use Container tabs. I tried with distinct Container tabs and it doesn’t work.

(Alain O'Dea) #7

IdP-initiated logins are not supported. You need to use an SP-initiated login URL like

In Okta, I use a bookmark app for this.

SonarQube explicitly sets an OAUTHSTATE cookie when the SP-initiated login URL is visited and checks for that cookie when the SAMLResponse is posted to the ACS (Assertion Consumer Service) URL at It is not possible to set a working OAUTHSTATE cookie from an IdP-initiated login flow.

(Reilly Brogan) #8

I was able to get it working using a bookmark app in Okta.

(Julien Lancelot) #9

Thanks for explaining the solution @AlainODea !