My use case: Auth0 is the service provider for PingFederate IDP using SAML. I have configured PingFederate with metadata.xml that I created following the Auth0 ping federate documentation.
A few important setup notes:
I have configured my application’s callback URL for localhost (doing local PoC)
I have enabled my PingFederate connection for the application
I have ensured that authorization code grant type is enabled
Up until the callback, everything works as expected. My flow works locally:
I can run my app locally
can click through to the lock widget
I get redirected to the PingFederate SSO login page
I enter my SSO credentials
I then see the redirect happen to Auth0 at {AUTH0_APP_URL}/login/callback
and redirect again to my local app at localhost:3000/callback.
I expect my callback route to get called with with an authorization code and my state variable. With that code I can exchange for a token, and be off to the races.
I do not get either in response. Instead I get my SAML response and nothing else. This was unexpected.
If I didn’t care about getting metadata about the user, or making subsequent requests with a JWT…I would be fine. But I actually do want that JWT!
I can verify from Auth0 logs that I am successfully logging in, and Auth0 has captured metadata about my PingFederate user.
I am pretty new to this, so I’m sure I’m missing something pretty obvious. Thanks !
Also, sorry for double post. I couldn’t find out how to delete an image from an existing post.
From the information provided the most likely cause for this is that you’re actually triggering an IdP-Initiate login through PingFederate. For IdP-Initiated the connection in Auth0 may be configured to forward the authentication to a specific application and one of the possibilities is to forward as a SAML protocol response.
You should check the connection settings in Auth0 to see if IdP-initiated is configured to send a SAML response to the application in question; if it is then this would explain the flow.
The recommendation would be to revise the configuration; I would say that the URL you configured to start the login with Ping is specific to IdP-Initiated so you should check their docs to obtain one for SP-Initiated (this page may be relevant - Ping Identity Support).
@mackenzie-orange responded via email and not to the topic directly. The email read as follows @jmangelo:
Joao,
I found the IdP-initated tab of my connection and switched it from SAML to OpenID Connect. I now see that my code is returned in the get request to my callback route!
The only missing is the state variable. I see the authorization code, but no state variable in the callback request. I guess I could remove that check in the boilerplate application I downloaded, but that seems like a bad idea.
Why might the state variable not be passed through?
Also, the IdP-initated tab is a little confusing. I am not using IdP-initated SSO, so why do I need to set anything here? There seems to be no way to disable it. I just have to choose an application and a type.
!