Single Sign-On (SSO) does what it says on the tin: it lets you use a single set of login credentials (typically username and password) to access multiple systems. There’s two main flavors of SSO: SAML2 and OpenID Connect (OIDC).

OIDC

OIDC is the (relatively) new kid on the block and is sometimes known as “Social Login” because it started life on social media platforms like Facebook and Twitter.

It’s been adopted by the business world too and you will doubtless have seen “Sign in with Google” buttons which let you login to other applications with your work G Suite credentials. Signing in with Microsoft’s Azure AD / Office 365 is also reasonably well supported by many web applications.

The downside of OIDC is that it relies on individual web applications supporting your flavour of OIDC. It’s very common to find applications that support G Suite users, but not Azure AD — that means there’s a “Sign in with Google” button, but not “Sign in with Microsoft”.

G Suite and Azure AD are both examples of Identity Providers (IdPs). They store details of all your users, what roles they have, and their login credentials.

There’s plenty of other widely used IdPs out there though – Okta, OneLogin, JumpCloud to name but a few. Although these might support OIDC it’s incredibly rare to see a “Login with Okta” button.

This is where SAML (Security Assertion Markup Language) comes in.

SAML

The first version of SAML (we’re now on SAML2) originated nearly 20 years ago, at the time that large organizations started to use more SaaS applications. Users would fire up their computers in the morning, login to their corporate networks, and then be repeatedly prompted to login to different SaaS applications.

Applications that support SAML are able to seamlessly communicate with corporate Identity Providers (like Microsoft Active Directory) to confirm the identity of users wanting to access them.

OIDC vs SAML

Whereas OIDC relies on the application supporting your specific Identity Provider, SAML relies on the IT team configuring the application. This at least means that ensuring single sign-on is under your control (providing the application supports SAML of course!).

SAML2 also supports something known as IdP Initiation. That means that a user can click on an application icon in your Identity Provider, and a password-less login to the application is done behind the scenes. OIDC isn’t always quite as seamless, and may require users to re-login, or click a further link.

On the flip-side, because OIDC doesn’t require prior configuration, if your IdP is supported by an application then the sign-up process for testing or checking-out a new tool can become incredibly quick — there’s no need to first create a user account, set up a password and confirm everything through an email link. Just don’t forget to revoke access to the tool from your IdP if you want to stop using the app. OIDC also acts as a layer above something called OAuth2, which makes it easy to let different SaaS applications connect to each other.

The best of both worlds?

If you use G Suite, you get the best of both worlds — the most widely supported OIDC “Social login” provider, and the ability to configure SAML2 access.

That’s not to say that G Suite should be your Identity Provider of choice — Google only started taking SAML and corporate identity management particularly seriously a few years ago, so other products are more mature in this space. That’s a topic for a whole other article.

SSO policies

Applications that support SAML often let you create rules to ensure users can only login using SAML. This can also be true for OIDC “Social logins”, but it’s less common.

It’s worth exploring what SSO policies your SaaS applications allow. Some offer more fine-grained policies, such as only letting users have access to administrative features if they’ve connected using SSO.

Restricting access to SSO offers some pretty significant security benefits and it might shape your thinking about the applications you procure.