For a bunch of months now, we’ve supported (tax-free) Google SSO for login, which you should think about using if you can, because if Google is already your source of truth for identity, it’s hard to do better for dependent services than SSO, which gives you built-in MFA, Passkeys, and all that stuff.
For many months prior to releasing Google SSO, we supported Github for SSO. I don’t know why we did Github first. I may even be wrong about that. Either way: we do.
To do this, we allow you to “lock” specific organizations to SSO. That’s a security best practice: if you tell us your org banana-stand uses Google SSO, we won’t let people slip into that org using an old stale user/password login.
But did you know that you can require both Google and Github SSO for an org?
We didn’t!
But, after an intrepid customer attempted to enable this configuration, tripping over a bug (that bug: an explicit “don’t let people enable two SSO providers” exception raised in our backend), we got around to making this work (by removing that exception raiser and writing a bunch of tests).
So: you can now set some of your orgs to require Google SSO, others to require Github SSO, and still others to require both Google and Github SSO. Which is a neat feature!
This is a consequence of our new Macaroon token system, which expresses SSO requirements as a “third party caveat” (a kind of token restriction). Our tokens allow you to stack arbitrary caveats. If you’re nerdy that way, you can check out that blog post and learn how to stack third party caveats of your own onto our tokens; our tokens have a plugin system!
We’d like to get around to adding additional (and custom) OIDC IdPs to our SSO system, and mostly what’s preventing us from doing that is people asking for them; in fact, there are several SSO-type features on our agenda that are paused waiting for someone to ask for them. So if you’re looking for more SSO-type stuff, be noisy about it!