We run an ecommerce site with it’s own sign-on system. We’re trying to integrate with a vendor such that they provide an SSO and their users can use our site without creating a separate account on our site. Fairly standard stuff.
Where I’m concerned is that they want us to authenticate users via their Auth0 account, not our own. From what I can tell, they plan to setup our site (and a bunch of others like it) as applications connected to their Auth0 account.
I’ve been unable to find any examples or docs that support this usage pattern, which has me concerned. I’m also concerned that implementing this way would complicate (if not prevent) us from using Auth0 to provide other sign on options.
Am I worried about nothing, or should I continue to be concerned?
If I’m understanding your scenario, you have an application using Auth0 for authentication, and you want to allow a vendor to use your application, and set up a federation so that your application trusts their users, which also happen to be based on another Auth0 tenant?
If I’m on the right wavelength there, then I think the best way would be to create a connection in your tenant, which is pointed at the vendor’s Auth0 tenant’s endpoints.
This could be a custom social connection using OAuth2, or alternatively, they could set up an application in their tenant to handle SAML requests, and you create a SAML connection in your tenant pointed at it. This guide for setting up SAML between two tenants should be helpful, the difference being the vendor owns the “Identity Provider tenant” in your scenario:
This way, the vendor’s users can login using their own Auth0 accounts, but you still control access to your applications as you can apply roles and permissions as you see fit, or even block users/disable the connection and so on.
You may also want to make use of the connection parameter in /authorize requests to your tenant, where possible, to skip your tenant’s login widget and send the vendor’s users straight to their tenant for authentication - if they are already authenticated with the vendor’s tenant, then they will be redirected back straight away to your app as authenticated, achieving SSO. This is often done via a vanity URL the vendor’s customers use, or a separate button on your application for their users to add the right connection parameter to the request.
To clarify - we aren’t (yet) an Auth0 customer, but are interested in migrating that way in the future.
Our vendor is insistent that we setup our application (and those of every other site they integrate with) as applications inside their Auth0 tenant, rather than as separate tenants using a solution like you provided above.
I’d much rather we have our own Auth0 tenant as you described, so that we have both administrative control and visibility into it. And because, frankly, it seems like the right way to proceed.
Can you point me at any resources that explain why sharing an Auth0 tenant between unrelated businesses like they propose is a less than ideal solution? That’s what I really need to bring to the table at this point.
Hi @lostapathy - sorry I made the assumption you did have an Auth0 tenant.
If they want to use their Auth0 users to log in to your app, there will need to be a federation of some kind set up between your app and their tenant, which would require a client/application on their tenant to represent your app (the service provider). This is like creating an application in Azure to allow users to log in via their Azure AD account - Quickstart: Register an app in the Microsoft identity platform - Microsoft Entra | Microsoft Learn
We support third-party applications, and your vendor should be using them in this scenario to lock down the content of ID tokens etc. for consumption by a 3rd party as they don’t control your app as I understand it - First-Party and Third-Party Applications
I can’t provide much help with your own login implementation unfortunately, but at a high level it would need to treat their Auth0 tenant as a trusted IdP for SSO to work, i.e. making OAuth or SAML based authentication requests to their Auth0 tenant to authenticate the user, and handling the assertion/callback in your app as you see fit.
Basically, the same flow as I described before, but without an additional Auth0 tenant handling some of the auth flow and user management for you - that would need to be done within your app.
Thanks @sgo - I got some details back from our vendor to clarify.
“In Auth0, (vendor) sets up (our company) with it’s own unique ClientID in the application setup of (vendor)'s tenant.” And then they describe us using the Auth0 client library to authenticate - which I think treats us like a “first party” app on their Auth0 account.
Is that good practice? If I’m reading your prior reply correctly, it feels like it would be preferred if they setup their tenant to let us talk either OAuth or SAML to it like a third-party app, rather than treating it like a first-party app.
Hi @lostapathy - the client library could be used with an app designated as a third party, although a little odd to prescribe the auth0 client library in this case, your app just needs to be able to treat their tenant as a trusted IdP through whichever libraries/protocols your app can support. If you are using OAuth, your app needs to be able to trust the tokens their tenant provides to create the local session, if you are using SAML, your app needs to trust the SAML Assertion their tenant provides to create the local session etc.
Generally speaking, as the owner of your application it is up to you whether to allow federated login with external providers or not.
Auth0 can be configured to handle any of the protocols here: Protocols
It would just be down to them configuring the client representing your app on their tenant to allow the relevant protocols you will be using to authenticate their users.
If you decided to use say, SAML, to authenticate users accessing your application against their tenant, then they would carry out the steps listed in this document, and your app would need to be able to construct SAML requests to send to Auth0, and process the SAML assertions Auth0 returned. The vendor would provide the URLs to point your app at to begin a login or logout as detailed here: https://auth0.com/docs/protocols/saml-protocol/configure-auth0-as-saml-identity-provider#configure-service-provider