Single-Sign-On
Notes on general principles regarding authentication via Single Sign On
Important Terminology
- Identity Provider (IDP): The server / service that is the system of record for the actual user information.
- Service Provider (SP): A service that you would like to log into using the credentials stored in the IDP
- Just-in-Time Provisioning (JIT Provisioning): Allows you to create or update users dynamically when you enter a Service as part of the SSO process
- Ex. When you enter a service, if the local, service-based user doesn’t already exist for the given IDP user credentials, the SP will automatically create a user for those credentials on-the-fly without any additional pre-configuration required.
- Note: Does not support (or make sense to support) de-provisioning of users; why would you send someone through the SSO flow just to de-provision them? You’ll need to support this via some other mechanism
Available Protocols
- Two most popular methods for setting up SSO:
Authentication Flows
With most SSO configurations you can allow for users to authenticate directly from the SP, redirecting you to the IDP for authentication and back to the SP (Service-provider-initiated auth), or from the IDP directly into the Service (Identity-provider-initiated auth). These are two different means to the same end.
Some examples of places with further documentation on this point:
IDP Initiated Authentication
- You start by logging into a central IDP (like Okta)
- From there, you can log directly into the different Services that your IDP has been pre-configured for
- Ex. Log into Okta and see the links to Salesforce, Google, Asana, and LucidChart.
SP Initiated Authentication
- You start by navigating directly to the Service that you’d like to log into (e.g., SFDC)
- A link or button or redirect is set up in order to send you back to the IDP for authentication purposes
- Once you’ve authenticated, you’re redirected back to the service and authenticated to that Service
Common SSO Design Patterns
- Hub and Spoke: You log into one central IDP, and that IDP provides a jump-off to other services
- This is similar to Okta or OneLogin
- Login Discovery: When there are a lot of different potential sign on options (e.g., Google, Facebook, Twitter, Corporate, etc…), then you could restrict the login form to a single identifier, like a phone number or email address, and then you look up behind the scenes which IDP to forward them to.