I guess there could be different approaches to this problem. Once could be creating two different applications in Auth0, each having different connections enabled. One would be “Main application” (with the associated database connection) and the other a “Connected accounts” application (with Intercom and Salesforce connections enabled for it).
From your app, you’d use one or the other client ID depending on the use case you are acting upon:
- Regular user login
- Associate an external account
Another option would be to use just one connection and pass the “connection” parameter in the
/authorize request from the application. You’d have three actions:
- regular user login (you could pass
connection=your_Db_connection or code the hosted login page to use a sensible default)
- Associate a salesforce account (you’d pass
- Associate an intercom account (you’d pass
The login action would have a normal callback processing (you get the ID Token with the user information, and you create a session for the user in the app). The “Associate” action would ask for a response in a different endpoint (e.g. “/callback_associated_account”), where you’d get the results of the secondary account. At this point, in your app, you have the user logged in under the primary account and you also know the secondary account chosen by the user.
You can then “link” the accounts in Auth0 (https://auth0.com/docs/link-accounts). This causes different identities to be linked together so that the user can use any of them to log in and the application always sees the user id of the primary identity as the user logging in.
Note that, depending on the identity provider, you might or might not be able to access the access token from the identity, and you might or might not be able to access a refresh token. If you can’t get a refresh token, you’ll need to ask the user to log in again using the social identity when the existing access token expires. The salesforce connection, IIRC, won’t store a refresh token.
Another option would be to use Auth0 for user authentication (using a db connection or any of the other options) and for OAuth2 API authorization if you need to, but ask the external services like Salesforce and Intercom for an access token and refresh token directly from the application (no involvement from Auth0).
These are all building blocks that you can use to build your use case. Unfortunately there’s no sample for the exact scenario you have, the possibilities and combinations are just too many. Hopefully this gives you a head start on some concepts and ideas.