When it comes to alternate methods of authenticating users in your community you have three options outside of the built in local authentication process.
For the purposes of this document we will refer to two actors, the “consumer”, which will always be your community platform, and the “identity provider” or “IDP” which is the third party responsible for collecting and verifying a user’s credentials.
Cookies Based Authentication
This method requires a specific encrypted cookie to be generated by the identity provider to be presented to the consumer. This cookie provides evidence that the identity provider has successfully authenticated the user as well as provides pertinent information about that user to the consumer in order to identify or create the user on the consumer.
Limitations
- Potentially requires custom development on the identity provider. The identity provider must create and transmit a specifically formatted and encrypted cookie, meaning this might be additional code on the identity provider.
- The consumer and identity provider must exist in the same root domain. This is the nature of sharing cookies across websites.
Fore more information see Cookies Authentication .
Open ID Connect
Open ID Connect, or OIDC, is an extension of the Oauth 2.0 specification to allow users to be identified and authenticated in a cross domain system. This means that the identity provider and consumer can exist in different domains. It is standardized so custom development on the identity provider is generally not needed if the identity provider is OIDC compliant. It works by redirecting a login request to the identity provider for the user to enter their credentials. Upon authentication the identity provider redirects the user back to the consumer with a unique, short lived code that the consumer then uses to exchange for a JSON Web Token (JWT). This token provides evidence of authentication and details about the user to be used by the consumer to identify or create the user.
Limitations
- Community only supports the confidential authorization code flow with a client secret.
- While the majority of OIDC compliant identity providers should work(assuming they support confidential authorization code flows), currently only Okta and Azure AD have been completely tested and certified.
For more information see How Do Setup and Configure SSO Using OpenID Connect?
Custom Identity Providers
If you have a different identity provider or want to implement your own, this is possible with custom development. See Single Sign-On Plugins for the steps to create your own authentication plugin.
Do Community Features Like Sliding Expiration and Normal Expiration Work with Single Sign-On?
If the single sign-on provider is built using the Single Sign-On Version 3 framework in community introduced in 12.1(OIDC and Cookies both do) then yes with a few limitations you must be conscious of.
Once a user has authenticated with an identity provider, the session is then managed internally by the community. Meaning that the actual logged in state is no longer governed by the logged in state of the provider which will generally manage its own state or session. When logging out of the community, the community will attempt to terminate the session on the identity provider, however logging out of an identity provider will not terminate the session in your community. This means that the token or cookie lifetimes should generally match your community timeout settings, or be longer.