Auth0 Home Blog Docs

Potential non-conformance with SAML's AudienceRestriction

Hey there Auth0 folks :wave:,

many of our customers at GitHub use Auth0 as their idP of choice to enable SAML SSO with our Enterprise Cloud offering. We recently ran an experiment to determine if a change in our runtime would break our customers SSO setup. This change was, unsurprisingly, that we didn’t get quite right a part of the SAML spec and it prevented some legit customers from using SAML.

We’ve been running it for about a week and a half, and for the vast majority of our customers it seems to work as expected. But for a very small subset, it breaks: where it should allow log-in, it would be rejected. This is due to what appears as an invalid SAML payload. We’ve only found this problem with payloads coming from Auth0. Here is where you folks come into play and I hope you could help me clarify this :bowing_man:

The specification indicates in this document pslam 566-567, that:

The assertion(s) containing a bearer subject confirmation MUST contain an AudienceRestriction including the service provider’s unique identifier as an Audience

Here is where we find a non-conformance from a very small subset of Auth0 customers, whom seem to be sending their assertions without an Audience in the SAML Response, but do indeed include the bearer subject confirmation. Our runtime expects this to be there, so the response is rejected as invalid.

I’ve never used Auth0, but I’m going to assume the AudienceRestriction is something that can be configured at Auth0’s SAML idP. We plan to reach out to those customers and ask if they can change their configuration, but my question is: is there something Auth0 should do about this? Should your implementation maybe prevent what appears as an illegal configuration and avoid the situation in first place? Something like “hey we’ve seen you’ve decided to send the subject bearer confirmation, but haven’t enabled AudienceRestriction, so we are going to go ahead and enable this for you”.

If you believe this is not an illegal configuration, could you please elaborate why and what’s your take on this part of the spec?

Hopefully I’m not asking for too much! Thanks in advance,

Hi Víctor. Thanks for reaching out!
I’m contacting you via DM to get more details on this, to see if this is something we need to fix for everyone, or to provide exact instructions if customers need to do something on their end.

1 Like

A quick update in case anyone lands in this thread: Víctor and I have been working on this and, as a result, Auth0 now has two new documents online to help configure Auth0 as the identity provider for GitHub:

Thanks Víctor!

1 Like