Whether or not to use SSO as the authentication method for your community is up to you. However, if you do plan on using SSO for your community, here are some best practices that we have identified that will help you on this part of your community journey.
Either SSO or Default-auth - ideally, not both at the same time
Many communities have widely differentiating target audiences, serving both customers and prospects for example. This often leads to the question whether you can have diverging login flows, where customers log in using SSO and prospects use the inSided default username/password login flow.
While this functionality is fully supported, we usually recommend against this setup. The main reason for this is that if a user is added to the SSO after using the default authentication method, his or her email may be different, leading to all their past community activity being lost when they move to the SSO.
What is the best way to manage my users - in inSided or in my own IDP?
Generally-speaking, it is preferred to manage users in as few systems as possible. In addition, it’s also better to manage your users inside your own IT-ecosystem. Managing your users in a system outside of inSided allows you much more flexibility in the future, as you will inevitably one day want to have (a subset of) your users log in to yet another system, so having their authentication information stored in something like Okta will help tremendously, in that case. Furthermore, user data is your data and inSided is not set up to support a comprehensive user management flow.
If at all possible, take the effort before launch, to get your user management in order.
SSO has multiple flavors, use one only
There are two models when using SSO:
-
SSO as an alternative to username/password
You often see this, where you can log in with e.g. your Google or Twitter account. Login with these 3rd party accounts does not alter your user in any way shape or form, it is purely used for authentication. The user is verified to be that specific user, but no rights are granted. -
SSO as authentication
Mostly used in enterprises, where something like Okta is used to both authenticate and authorize the user to specific applications.
This is what we see a lot with our clients, where they allow their customers to log in using the same SSO and credentials as used with their main product. Based on this SSO-login, they are granted a custom role “customer”. -
Mixing these two models/purposes is bound to lead to issues. Only when you have an SSO-only setup, should you consider using SSO for authorization and/or granting rights.
Private Community & SSO
If you end up using only SSO as your login method for a private community, a few items on the login page become redundant. Do avoid community user confusion, we recommend that you either change the wording and links on this page, or hide them altogether. To do the latter, check out this article for a step-by-step guide.
Do you have your own best practices? Feel free to add them below, and we will update this documentation as new ideas are added below!
-----
Last Updated: March 20, 2023
