Here is my use case: Let user logina nd then connect to Intercom and Salesforce via OAuth. So I have a simple Login form that users use to register. After that I want to show them “Salesforce Login” and “Intercom login” buttons. Once the user clicks on each one of them I need to do OAuth with each of those and add the resulting tokens to the currently logged in user. I can then use the respective tokens to do some business action.
Right now I have both user authentication and Salesforce authentication working. But the thing since I have enabled Salesforce login in Auth0, it also shows up on the Auth0’s login screen. The first problem is how to hide the Salesforce login button from the Auth0’s login screen?
Secondly, I don’t want Salesforce login to become a second user, they are the same user and I just want to add Salesforce info into the same user. How can I do that? I believe we can use some rules, but I’m having hard time understanding how that would work. Can anyone please show me some specific example?
1 Like
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
connection=salesforce_connection_name)
- Associate an intercom account (you’d pass
connection=intercom_connection_name)
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 (User Account Linking). 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.
1 Like
Hey team!
This topic seems related to our new EA feature, Forms for Actions, which rolled out of the beta stage on May 7th. Our Product team prepared the whole Documentation page with examples of Use cases. Forms for Actions. If you find yourself having questions regarding this new feature for the next two weeks, we are hosting an Ask Me Anything session. Our Product Expert will provide comprehensive written answers on May 21st from 8 AM to 10 AM PST.
Find out more about Forms for Actions and learn more about AMA.
Thanks!
Dawid