Recommendations for LiveBetterWith SSO/API Set up:
LBW asked:
We need to understand why it is not recommended to create a user via the API and what cons or problems we can expect?
The documentation is very unclear on this and we'd like to understand the potential problems please as it may be required for us to do this in order to have separate condition communities and provide a reasonable UX.
I asked them why the heck they want to create users over the API rather than simply have users created as they log in to SSO for the first time:
We want to add a user via the API in order to provide an improved user experience for the user and not have to store and pass roles via SSO.
Our current design has us registering a user and verifying their email, once this is done, we want to create the user in Vanilla via the API but then ask additional questions to the user before taking them to Vanilla and assigning further roles to the user via the API, which will determine their role in the Community.
I hope this is clear. Ultimately, we want to create the user once they have verified their account but SSO creates the user in Vanilla as the final step - we want to create the user before the final step so that we can update the user in Vanilla and not store this information on our side.
Sounds to me like they are trying to avoid passing roles over SSO and using the API to assign these roles instead, not sure if that is problematic/futureproof.
If this is going to cause them problems down the road, I'd like to get out in front of it.
Advice for them?
Comments
-
Just as a note Shauna, you might be running into the same thing with Tesla as well. Their question was about "we need to assign roles in a scalable way but may not be able to do it via SSO and thus are thinking of using the API". From my conversations with both Linc and Todd it seem to come down the need for a webhook for that to properly work.
0 -
After a call with @Linc they still seem adamant to use the API to create users as part of their SSO process:
Initially I see no problem on creating a user through the API and then use SSO to log them in. And, as far as I remember, I didn't hear / understand any reason against that from Lincoln, apart from "it's not the way it's supposed to work".
So, I'd really appreciate if you could tell me the reasons why creating user through the API is not recommended.
0 -
Before I explain, a couple key negotiation points
- Always readily admit it's possible to do this, just inadvisable. Acknowledging that it makes sense on the surface typically puts you in better position for them accepting the rest of this. We're not going to stop them, we're just delivering a strong warning.
- We have a tremendous depth of experience with this. We have helped many hundreds of customers do what they are doing. Their team has probably done this a few times or this is their first time. This needs to be clear to them (as diplomatically as possible - emphasize our experience, not their lack of it of course).
Now let's set the stage by differentiating SSO vs. API vs. Webhook
- An SSO system is lazy (which in this context is extremely good). This means nothing happens until the user triggers it (by navigating to the forum and using it), and all actions happen within the context of the user's actions, nearly guaranteeing success. The worst case scenario is they get a meaningful error message.
- Registering a user over API introduces a blocking condition: The user cannot login properly if an API call outside their control has not completed successfully. This sets up a synchronous workflow: 'A' must happen before 'B'. API calls sometimes fail. The Internet is fallible and each of our systems are fallible.
- A webhook (which we currently lack) in this scenario would call out from Vanilla to their system (the opposite of an API request directed at us) at the time of first login to retrieve the necessary information from their system. This would be much better at addressing this problem (than calls to our API) because it is a lazy request (it doesn't happen until it's needed).
So here's the summary
SSO is designed to be fault-tolerant to deliver the best possible user experience consistently with the least amount of setup time required. Users aren't created until they are needed ("just-in-time" or "lazy loading") which means less transactions to monitor and much higher likelihood of consistent success.
Creating an equally fault-tolerant system using synchronous API requests requires a self-auditing system to make sure those calls are all successful (and automatically retrying the ones that are not) in addition to creating a blocking condition where it's possible a user would not be able to login if for some reason the API call was delayed.
And the punchline
An API-based registration system is far more likely to generate support requests and general headaches for both parties because it adds sync problems and the possibility of mysterious user-facing errors that are very difficult to diagnose.
4 -
"API-based registration" = "Begin the countdown to the first support request" about 'why X user didn't get Y permission' or 'why didn't Jimmy's account connect to the one we created for him' or 'can you please merge these accounts because something went wrong' and it's just gonna get worse from there.
0
