We have a requirement to authenticate our client’s users using their SAML 2.0 IDP (PingFed). Additionally, we will need to relay this authentication to a 3rd party system which also authenticates using the same IDP. APIs of this 3rd party system will be called from ours.
My understanding is that if this were an OIDC flow, we could use the Auth0 Management API to retrieve external IDP tokens as described in the documentation under the Secure | Tokens | Access Tokens | Identity Provider Access Tokens section as well as in the Authenticate | Identity Providers | Calling An External IDP API section.
Given this is a SAML flow, what are our options here?
Hello!
Given your SAML flow with PingFederate via Auth0 and the need to authenticate to a 3rd party system, directly relaying the SAML assertion as an API token is generally not feasible as SAML is for authentication, not API authorization. The recommended approach is for Auth0 to act as a bridge: users authenticate via PingFederate into Auth0, then your application receives standard Auth0 OIDC/OAuth tokens.
Hello @Gina638Rod,
Thanks for the answer, I really appreciate it.
It’s as I feared, I suppose. The only common component between our system and that 3rd party one is PingFed. Somehow, we need to translate an Auth0 token to whatever auth federation system that 3rd party is using, since it may not be Auth0 or even PingFed. Since I can’t assume they’ll be able to translate Auth0 tokens, do you have any suggestion on how to proceed?
If the 3rd party system authenticates using the same PingFederated IdP as the Auth0 application, their session should be detected whenever they try authenticating on the respective system.
Have you attempted to test it out to see if the session is being detected by the said system after authenticating via the SAML connection through Auth0?
Yes, that’s the case were we to forward users to the 3rd party system. In this case, though, that system is accessed as an API from our backend. What we need is to pass-through the authentication of the user and have it recognized by that 3rd-party system.
With OIDC this is a simple matter of forwarding the token (JWT or otherwise) along with any request. With SAML, I don’t know.