Auth0 Home Blog Docs

SAML2 Webapp Addon unintended behaviour



I’m having trouble with the SAML2 Webapp addon since last week.
To give you some context, i have two applications, one is embedding the other in an iframe and they both use the same connection.

The first application is mine i’m using an ADFS connection to get authenticated on this one. The other one is an external application we’re embedding that can only use SAML2, so i’ve configured the SAML2 Webapp addon accordingly.
Everything was fine until last week when i couldn’t be authenticated because the SAMLResponse was never sent to the external application and i was directly redirected to the first one.

Edit :

For some further context :

  • Both applications use the same client
    entry on my tenant
  • Embedded or accessed directly, I
    experience the same issue.
  • The first application use the hosted
    login page on Auth0 to redirect the
    user to an external ADFS
    IdentityProvider, the other one
    should be accessed after you’ve been
    authenticated to the first and the
    SAML Flow should be seamless for the

The hosted login page is pretty simple and is something like that :

  var auth0 = new Auth0({
    domain:       'AUTH0_DOMAIN',
    clientID:     'AUTH0_CLIENTID',
    callbackURL:  ''
        connection: 'adfs-idp',
        response_type: 'code',
        scope: 'openid name email',

The SAML2 Webapp addon is pretty straightforward too :

callback :

  "mappings": {
    "1st_id": "XXX",
    "2nd_id": "XXX"
  "recipient": "",

Here’s what i experience when i try to access the second application directly :

  1. Access
  2. Redirect to with the SAML Request as a GET Parameter
  3. Redirect to https://Auth0_domain/login?client=CLIENT_ID&protocol=samlp&SAMLRequest=XXX&RelayState=XXX&
  4. Since i’m redirected to the login endpoint i’m accessing the hosted login page and automatically redirected to

Do you have any idea why i’m experiencing this behaviour ?


I’m afraid some additional context will be required in order to further troubleshoot this situation. In particular, you mention two applications; do each have their own client application record in Auth0? Can you reproduce the issue on the SAML one without the embedding on the other one (no iframes, just accessing the SAML one even if from an UI perspective this does not make sense)? The more we reduce the repro steps the easier it will be to troubleshoot. Also, you should provide the configuration you’re using (you can redact the sensitive parts like app specific URL’s).


@jmangelo Is it enough or do you need more information ?


Thanks for getting back with an update; it’s sufficient information for further analysis so I’ll get back to you if I find anything relevant. At first glance, I would not expect the two application to share the same client identifier, but not sure if that can explain the issue in any way. If it were me, I would split into two client application and only have the SAML addon on the relevant one. Ideally, you can do this in a test tenant in order to not have any additional side-effects.


@jmangelo , everything is back to normal now. I’ve made no changes on both the application2 ServiceProvider and Auth0, i’m missing something here :frowning:


I have to confess that I can’t come up with an explanation, I reviewed the recent changes and the only one somewhat associated with SAML handling was for IDP-initiated so on top of being a non-functional (code refactoring) change it’s also for an aspect of SAML handling that does not seem to apply to your use case.