Troubleshooting generic 'Oops' error page (invalid_request) with SAMLP Identity provider connection

I have been configuring a SAMLP Identity provider connection by following this documentation, which has been mostly successful:

However, when I initiate the login through my identity provider app (Okta), I see:

  1. The SAML token is generated and posted to my Application Callback Url / Assertion Consumer Service Url (which looks like this: https://mydomain.auth0.com/login/callback?connection=MyConnectionName)

  2. The Callback Url / ACS Url responds to the post with a 302 and redirects to itself, plus a couple of new parameters: https://mydomain.auth0.com/login/callback?connection=MyConnectionName &code=SOME_CODE &state=MY_ENCODED_DEFAULT_RELAY_STATE_URL

  3. The Callback Url / ACS Url with the new params responds with a 400, and shows me the generic error page: “Oops! Something went wrong” with technical details that read:

invalid_request: You may have pressed
the back button, refreshed during
login, opened too many login dialogs,
or there is some issue with cookies,
since we couldn’t find your session.
Try logging in again from the
application and if the problem
persists please contact the
administrator.

In spite of the error page, the login itself is successful- as I can see because I can then hit my lock-widget-protected web-app, which shows in the “previously you logged in with” state and allows the user to proceed with a single click. The Auth0 logs also indicate a successful login:

  • Occurred: a few seconds ago at
    2017-08-22 21:17:53.925 UTC
  • Type: Success Login
  • Description: (empty)
  • Connection: MyConnectionName
  • Application: MyApplicationName (APP_CLIENT_ID)
  • User: (empty)

Raw:

{
  "date": "2017-08-22T21:17:53.925Z",
  "type": "s",
  "connection": "MyConnectionName",
  "connection_id": "con_A_CONNECTION_ID",
  "client_id": "APP_CLIENT_ID",
  "client_name": "MyApplicationName",
  "ip": "MY_IP",
  "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36",
  "details": {
    "original_profile": "{\"sessionIndex\":\"idSOME_ID_DIGITS\",\"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier\":\"user@email.com\",\"nameIdAttributes\":{\"value\":\"user@email.com\",\"Format\":\"urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress\"},\"http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod\":\"urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport\",\"issuer\":\"http://www.okta.com/SOME_OKTA_HASH\"}",
    "prompts": ],
    "initiatedAt": 1503436673720,
    "completedAt": 1503436673923,
    "elapsedTime": 203,
    "stats": {
      "loginsCount": 19
    }
  },
  "user_id": "samlp|MyConnectionName|user@email.com",
  "user_name": "",
  "strategy": "samlp",
  "strategy_type": "enterprise",
  "log_id": "SOME_LOG_ID"
}

My goals are the following:

  1. Get past the error with the Callback
    Url / ACS Url upon redirect

  2. Redirect to MY_ENCODED_DEFAULT_RELAY_STATE_URL
    after successful login (I think that
    setting a default relay state url is
    the way to achieve this)

How can I gain more information to continue troubleshooting this flow? I feel as though I’ve hit a dead end in terms of the generic error page (in spite of a SAML-driven session apparently being created), and no clues to chase in the Auth0 logs. I’ve experimented with many config permutations and I’m out of ideas. Thanks for your help!


Part 2:

After following the suggestion to change the Response Protocol configured in the connection IdP-Initiated SSO settings to SAML:

This seems to look closer to working solution, because I am now observing a sequence of successful POSTs to the ACS url, however there is no redirect to the RelayState URL. Instead, the sequence arrives at an infinite loop of POSTs to the ACS url with encoded SAML indicating an error state. Here is the observed sequence:

  1. Successful POST to ACS url with SAML form data (decoded, it shows Okta as the issuer), has RelayState
  2. Another successful POST to ACS url, (decoded SAML shows data from logged in user as attributes), also has RelayState
  3. (This is where I was hoping that the Auth0 application as the Service Provider would redirect to the RelayState url, but this does not happen)
  4. An infinite sequence begins with more POSTs (response code 200) with decoded SAML in the form data for the request showing a statusMessage that indicates “invalid thumbprint”.

@jmangelo you also wrote that “The fact that the redirect targets https://[tenant].auth0.com/login/callback?connection=[saml_connection] suggests that there is some incorrect configuration, because this redirect should be targeting an URL within the control of the client application itself.” - Is there some other place where I should be configuring the redirect from Auth0 as a Service Provider to my final destination end-user-webapp besides including a RelayState in the POST that’s initiated by the IdP? Should the Application Callback Url as configured in the SAML2 Web App Addon for my client application not be set to the ACS url? Thanks again.


Part 3: Solution!

After more experimentation, I’ve finally got a working solution. It turns out that the correct configuration for me using IdP-initiated SSO in this case was the following:

  • Using OpenId Connect as the Response Protocol
  • Moving my end-user-webapp url to the top of the list in my allowed callback urls for my Auth0 Service Provider application. I suspect that adding a redirect url in the query params field would have also sufficed. Perhaps RelayState had nothing to do with it.

Anyway, I hope this post can be helpful to others.

@jmangelo from reading other forum answers, I presume this might be within your domain of expertise- can you provide any insight?

Thank you,
-Dan

@jmangelo from reading other forum answers, I presume this might be within your domain of expertise- can you provide any insight?

Thank you,
-Dan

I’ll take a look, to be honest SAML is not where I feel most comfortable but I’ll try. Just to clarify, you mention that you’re following this docs, but then you mention Okta. Can you confirm that although you’re following the docs about using Auth0 both as SP and as IdP, in your particular case, it’s Okta that ends up acting as IdP?

On another note, avoid posting what should be comments as answers as that may remove the original question from the unanswered queue which also reduces its visibility.

@jmangelo Thanks for the reply and I’ll mind that advice about posting comments here in the future.

To clarify some details about how I have things configured currently:

  • Okta is configured as the IdP (as a SAMLP Identity Provider in Enterprise Connections). Sorry if my statement about following the linked documentation made that unclear. My requirements are for Okta to be the IdP.
  • In the addons config for the Auth0 app, the SAML2 web app is enabled, and (only) an audience param is configured.

I’m happy to furnish any other details that could be helpful. Thanks again.

Based on the information you provided you’re configuring Okta as an enterprise connection and then are initiating a authentication/login operation from within Okta itself; this is generally referred as IdP-initiated SSO so the first thing to have in mind is that you need to be sure that the relevant settings for IdP-Initiated SSO are as you expect.

You can find these setting in the IdP-Initiated SSO section of the SAML connection general settings dialog and you can refer to the reference documentation for additional information about each one.

You mention that you configured the SAML2 web application addon in the respective application so I’m assuming that your client application wants to also use the SAML protocol and receive a SAML assertion instead of an OpenID Connect ID token.

However, on the second step of the process you described you mention that the endpoint that receives the Okta SAML assertion is redirecting to https://[tenant].auth0.com/login/callback?connection=[saml_connection]&code=[code]&state=[relay_state_url].

There are two issues with the above situation:

  • the presence of a code parameter suggests that the Response Protocol configured in the connection IdP-Initiated SSO settings is the OpenID Connect one. **In this situation, it makes no sense to have configured the SAML2 addon on the web application as what the client application will receive is a response according to OIDC and not SAML.
  • The fact that the redirect targets https://[tenant].auth0.com/login/callback?connection=[saml_connection] suggests that there is some incorrect configuration, because this redirect should be targeting an URL within the control of the client application itself. The URL that will be used in this redirect will be the first one present in the Allowed Callback URLs of the respective client application so this suggests that the client application is incorrectly configured.

In conclusion, in order to have a client application login a user based on a SAML connection and when starting the flow at the IdP, you need to make sure that the response protocol is the one the application supports and that the first allowed callback URL in the client application is correct and is prepared to receive that response.

@jmangelo Thanks for the reply and I’ll mind that advice about posting comments here in the future.

To clarify some details about how I have things configured currently:

  • Okta is configured as the IdP (as a SAMLP Identity Provider in Enterprise Connections). Sorry if my statement about following the linked documentation made that unclear. My requirements are for Okta to be the IdP.
  • In the addons config for the Auth0 app, the SAML2 web app is enabled, and (only) an audience param is configured.

I’m happy to furnish any other details that could be helpful. Thanks again.

Thanks for the reply, you were correct about changing the Response Protocol to SAML. I missed that. Now I am able to observe the following sequence:

  1. Successful POST to ACS url with SAML form data (decoded, it shows Okta as the issuer), has RelayState
  2. Another successful POST to ACS url, (decoded SAML shows user identity data), has RelayState
  3. (this is where I hoped it would redirect to the RelayState url, but it did not)
  4. Infinite sequence of more POSTs to ACS url with SAML data indicating invalid thumbprint

I’ll edit my question with more data since I’m out of space here.