
What is SSOSebby?
SSOSebby is a fork of SSOReady (YC
W24), which is an open-source,
straightforward way to add SAML and SCIM support to your product:
- SSOReady SAML: Everything you need to add SAML ("Enterprise SSO") to your product today.
- SSOReady SCIM: Everything you need to add SCIM ("Enterprise Directory Sync") to your product today.
- Self-serve Setup UI:
A hosted UI your customers use to onboard themselves onto SAML and/or
SCIM.
With SSOSebby, you're in control:
- SSOSebby can be used in any application, regardless of what stack you use.
We provide language-specific SDKs as thin wrappers over a straightforward
HTTP
API:
- SSOReady is just an authentication middleware layer. SSOSebby doesn’t "own" your users or require any changes to your users database.
- You can self-host yourself.
Getting started
The fastest way to get started with SSOSebby is to follow the quickstart for
what you want to add support for:
Most folks implement SAML and SCIM in an afternoon. It only takes two lines of
code.
How SSOSebby works
This section provides a high-level overview of how SSOSebby works, and how it's possible to implement SAML and SCIM in
just an afternoon. For a more thorough introduction, visit the SAML
quickstart or the SCIM
quickstart.
SAML in two lines of code
SAML (aka "Enterprise SSO") consists of two steps: an initiation step where you redirect your users to their corporate
identity provider, and a handling step where you log them in once you know who they are.
To initiate logins, you'll use SSOReady's Get SAML Redirect
URL endpoint:
// this is how you implement a "Sign in with SSO" button
const { redirectUrl } = await ssoready.saml.getSamlRedirectUrl({
// the ID of the organization/workspace/team (whatever you call it)
// you want to log the user into
organizationExternalId: "..."
});
// redirect the user to `redirectUrl`...
You can use whatever your preferred ID is for organizations (you might call them "workspaces" or "teams") as your
organizationExternalId. You configure those IDs inside SSOReady, and SSOReady handles keeping track of that
organization's SAML and SCIM settings.
To handle logins, you'll use SSOSebby's Redeem SAML Access
Code endpoint:
// this goes in your handler for POST /ssoready-callback
const { email, organizationExternalId } = await ssoready.saml.redeemSamlAccessCode({
samlAccessCode: "saml_access_code_..."
});
// log the user in as `email` inside `organizationExternalId`...
You configure the URL for your /ssoready-callback endpoint in SSOSebby.
SCIM in one line of code
SCIM (aka "Enterprise directory sync") is basically a way for you to get a list of your customer's employees offline.
To get a customer's employees, you'll use SSOSebby's List SCIM
Users endpoint:
const { scimUsers, nextPageToken } = await ssoready.scim.listScimUsers({
organizationExternalId: "my_custom_external_id"
});
// create users from each scimUser
for (const { email, deleted, attributes } of scimUsers) {
// ...
}
Philosophy
We believe everyone that sells software to businesses should support enterprise
SSO. It's a huge security win for your customers.
The biggest problem with enterprise SSO is that it's way too confusing. Most
open-source SAML libraries are underdocumented messes. Every time I've tried to
implement SAML, I was constantly looking for someone to just tell me what in the
world I was supposed to concretely do.
We believe that more people will implement enterprise SSO if you make it obvious
and secure by default. We are obsessed with giving every developer clarity and
security here.
Also, we believe randomly pumping up prices on security software like this is
totally unacceptable. MIT-licensing the software gives you insurance against us
ever doing that. Do whatever you want with the code. Fork us if we ever
misbehave.
Security
If you have a security issue to report, please contact me.