Single Sign On and IdPs#
Every app you use requires authentication – you have an account, and every now and then you need to prove that you are who you say you are, so you can use that account. The most popular method of implementing that is username and password, stored on company servers. But for reasons that are obvious to anyone sharing a Netflix account, this auth method is not ideal: you need a different username/password for every service you use, and passwords are very hackable.
In other words, most apps work with a decentralized identity model:
- Each app has its own database of usernames and passwords implemented differently
- Adding security features like multi factor authentication requires custom work
The problem with this model is, well, that’s it’s decentralized - every company needs to re-invent the wheel and implement security features independently.
This, by the way, is where companies like Auth0 make their money - they provide tooling that helps companies build authentication in house.
Single Sign On solves this problem by letting companies outsource their authentication to a third party, like Google or Okta. When you’re trying to log into the New York Times and click “sign in with Google,” the NYT is using Google as an outsourced identity provider: you log in with your Google login, and that proves that you are who you say you are. The whole process of checking your username/password against what exists in the database happens on Google’s servers, not the NYT’s.
To understand the basics of SSO, you need to know the terminology for both sides of the ecosystem:
- Service Provider (SP) – the app you’re building that needs authentication. In our example, the New York Times.
- Identity Provider (IdP) – the service your app is using for outsourced authentication. In our example, Google (more accurately, GSuite).
When a user attempts to log into the New York Times site (our SP) with SSO, the NYT site redirects them to Google’s servers (our IdP) to authenticate. If the user successfully signs on with Google, Google sends a message back to the NYT site saying “hey, all’s good, let this guy in.” If this sounds simple, it’s because it is! The hard part is in actually implementing this stuff, but thankfully that’s not your job (yet).
What Okta actually does#
Okta is an identity provider, so they’re one of the companies that other companies outsource their identification to. The easiest way to understand this is through the perspective of the user: let’s imagine today is your first day working at FedEx corporate (an Okta customer). FedEx uses a bunch of tools that you need access to: Looker for data, Salesforce for a CRM, and Gmail for email.
If FedEx is using SSO (they are), instead of a username and password for each of those tools, you have one Okta login that you use for all of them. When you load the Looker app, it will prompt you to sign in via Okta, and you’ll get redirected to an Okta login screen. If you authenticate with Okta successfully, you’ll get sent back to Looker and can get started.
This type of flow we just described is called SP-initiated, because you started the sign in process from the app you want to log into (Looker, the service provider), not from the identity provider (Okta). But you can also do IdP-initiated login: Okta provides a portal of all of the apps you have access to, and you can launch the app from there already authenticated instead.
The hard engineering work here is integrating your system with Okta and the various other IdPs that your customers are going to want to use (like OneLogin). The most popular open source protocol for doing this is called SAML (security assertion markup language), and it’s notoriously frustrating to work with.
SSO is Okta’s bread and butter, but over the years they’ve taken advantage of their position in the ecosystem (a central authority for identity) to build a strong supporting feature set. Like any enterprise-focused website, understanding these features is near impossible. Here are a few broken down:
1) Multi factor authentication#
You’ve seen enough public breaches to know that username and password alone isn’t particularly secure: authentication through multiple touch points (that security code sent to your phone, or the authenticator app) is getting more and more popular. Okta lets you require this for all of your users, and provides a mobile app (it has 2 stars in the app store!) to generate 2FA codes.
2) Directory sync#
Large organizations have hundreds of internal user groups with different permission levels – an engineering manager might have admin permissions to databases, while junior engineers can only read from those databases. Okta allows you to build a directory of these users and roles, and sync them with other apps like Github automatically.
3) Lifecycle management#
User Lifecycle Management (ULM) is the process of creating and deleting user accounts as people join your organization. Back to our FedEx example, when you join, your IT Admin will need to create accounts for you in Looker, Gmail, and the like – and when you leave, those accounts need to get deactivated so you can’t access company data. Okta provides tooling to do this automatically based on the directory settings you’ve configured.
The open source SCIM protocol (system for cross-identity management) is the most popular option for building these “directories” of permissions and automating user lifecycles. An example: if an employee leaves your company, you can set up SCIM and Okta to automatically de-provision their accounts.
Further reading#
- For a more in depth introduction to SSO and SAML, I wrote a beginner’s guide for developers here
- Okta covered SCIM in a beginner’s introduction here, and you can find the actual spec (for the technically inclined) here
