If two companies want to share back end api’s, and possibly also authorization, does Auth0 provide this?
An example would be I sign in with IdpA for companyA, then I want to call companyB API or it could be the reverse.
Is it necessary to share an Idp? or can we federate Idp?
How does companyB know about IdpA or tokens from IdpA if they have their own IdpB?
Hi @dmarsh26,
Thank you for posting in Auth0 Community!
Each organization might use different identity providers (IdPs) such as ADFS, Azure AD, G Suite, or username/password stores. Email domains can be configured against each enterprise connection as a way of routing authentication requests.
Auth0 supports several “Enterprise” connections for customers who wish to use their own federated IdP to provide SSO (Single Sign-On).
You can find more information in the following posts:
Hello lily, thanks for your reponse. The blog articles do not seem to cover my use case.
So I am talking about two seperate enterprises with different domains. Each may have their own Identify Providers or OAuth provider.
Both enterprises want to expose REST microservice API’s to each other and protect these resources with authentication and authorisation.
If a user authenticates with EnterpriseA OAuth/Idp, and then hits EnterpriseB REST API, it will not have a suitable token, are there any specifications or extensions to OAuth that allow something like this to work?
Must we share a common OAuth Authorization Server or a commain parent domain?
Should the back end services include hard coded service users? If so is there a way to allow impersonation?
many thanks
David Marsh
Hi David,
Thank you for the clarification. However, please note that the Community team can mostly provide high-level advice on your architecture. If you are considering implementing Auth0, I would suggest getting in touch with our sales team here as they can provide more information whether your use case is supported.
Most enterprise companies expect to be able to integrate their IdP into your application so their employees don’t need to store another set of credentials. This is a valuable way of simplifying the user authentication experience without compromising security, and using Universal Login makes it easy to start adding support for Enterprise Connections with minimal disruption. In this case, Auth0 is the SSO service provider. For example, if you decide to configure Auth0 as SAML Service Provider, you will add some information to the IdP so it knows how to receive and respond to SAML-based authentication requests from the Auth0 service provider.
If you have more than one application, the best practice is to redirect to a centralized location to authenticate the user. With Auth0, this means taking advantage of Universal Login, which provides many security and user experience benefits out-of-the-box, including SSO. More information on our authentication scenarios here.
Also, note that we support both when there is a user authenticated or not. When calling one API from another API, or from any situation where there is no authenticated user context - such as one or more cron jobs, report generators, or continuous integration/delivery systems - you will need a way to authorize the application instead of a user . This is a one step process where the application is authenticated (using a client ID and secret) and then authorized in one call. You can learn more about this in our authorization workstream under machine-to-machine (m2m) authorization.
Hope that helps!
Hi @dmarsh26
In addition to what @lily.wisecarver said, most middleware support multiple token issuers. The API could be configured to accept tokens from either.
John