Auth0 Home Blog Docs

Issue with IdP initiated SSO

lock
angular
sso
auth0js
angular-lock

#1

We are using Lock.js(v10), with auth0.js(v8), in an angular 1.X application. Our application is a Service Provider and we will be using our client’s ADFS as the IdP. As we do not have access to our client’s IdP during development, we have setup another Auth0 client as a test IdP.

Our client has been periodically testing our implementation by sending a valid SAML response as if it were from the IdP (but its not actually, they are using a custom HTML page to send the request). While this works, in that we see a successful login in the Auth0 logs, the user is actually left on the login screen of our application without actually being logged in. We were able to replicate this behavior by using the login URL of our Auth0 test IdP.

When the login is initiated from our application’s login button, the login works as expected, i.e you are redirected back to the login page and then logged in. When the login is initiated from the IdP login URL (so minus the first step of clicking ‘login’ on the application site), the user ends up on the login page of our application and is not then logged in. There are no errors in the console to investigate.

We also have IdP-initiated SSO set up with the correct default client and SAML as the response type.


Update

It looks like when the login request is IdP initiated, none of the required URL params are present on the callback URL.

i.e., when we login using the button, the callback request has #access_token=foo&… but when initiated from the IdP, there is nothing, and hence the lock is not triggered.

Why is this happening? What are we missing…


#2

The difference in the flow that works and the one that doesn’t is that one is SP-Initiated and the other is IdP-Initiated.

You mention that you configured IdP-Initiated with the expected client application, but then you mention that you selected SAML as the response type. I’m assuming you meant response protocol and if that’s the case it implies that a SAML assertion will be posted to your client application. However, the libraries you mention as being used in the client application do not support processing SAML assertions. This is consistent with the fact that you mention that when it works you see #access_token=foo&... in the URL; that is not a SAML response, it’s an OpenID Connect one.

You’ll need to change Response Protocol to be OpenID Connect so that the final stretch of the process is done according to the protocol the client application expects. In addition, you may also need to set the Query String to be response_type=id_token token so that the response tokens are immediately delivered in the fragment component of the callback URL.


#3

You, sir, are a scholar.

Thank you very much. This was driving me insane. Your explanation makes perfect sense and echoes what I was seeing!

Thank you again.


#4

You, sir, are a scholar.

Thank you very much. This was driving me insane. Your explanation makes perfect sense and echoes what I was seeing!

Thank you again.


#5