Whether you are new to the auth space or not, there’s a lot of overlapping terminology that can be hard to decipher. In fact, one of the worst examples is the word “auth” itself, which can refer to a number of different things. In this post, we’ll look at some common but confusing terminology and describe what each means with examples.
Authentication (AuthN) vs Authorization (AuthZ)
Authentication is determining who someone is in the first place. This is different from authorization, which is the process of determining if someone has access to something.
As an example, imagine we are building a simplified Twitter. Users can sign up, post tweets, and delete tweets. When we receive a request to delete a tweet, we need to do two things:
- Determine who made the request
- Determine if they are allowed to delete the tweet
For step 1, we need to authenticate and determine who the user is. This identity check is usually confirmed via username and passwords, biometrics, or a trusted third party, such as a social login. For step 2, we need to validate the user’s authorization, in other words, we are determining if that user is allowed to delete the tweet. Using the confirmed data from step 1, we can check if the user matches the profile of the sent tweet, and if so, we will grant them access to delete their own content.
Workforce Identity vs Customer Identity (CIAM)
Workforce Identity involves managing employees at your company whereas Customer Identity involves managing users external to your company. Authentication services typically provide either workforce or customer identity in order to target their customers’ unique needs.
Some examples of workforce identity tools are Google workspace, Rippling, and Okta. This is sometimes referred to as “internal auth” because you are managing employees within your organization.
Some examples of Customer Identity (also known as CIAM or customer identity access management) include PropelAuth, Auth0, or a self-developed login system.
Security Assertion Markup Language (SAML)
SAML is a standard for exchanging data between two systems. One common use case for SAML is connecting a customer identity system with a workforce identity system.
As an example, if you are building a B2B product, you’ll need to have some customer identity system, such as a system to login and register all of your customers. One of your customers might have a workforce identity system to manage their employees, such as Google workspace. Using SAML, you can enable seamless workflows like:
- Your customer can specify which (or all) of their employees get access to your product and even which features within the product they have access to.
- When one of your customer’s employees is off-boarded, they will no longer able to login to your product
- New employees will automatically get access to your product
System for Cross-domain Identity Management (SCIM)
SCIM is a standard that allows you to sync user data across different systems. One popular use case for SCIM is having a workforce identity system immediately send updates to a customer identity system as user and group information changes. For example, if a new employee is onboarded via Rippling, then Rippling will send PropelAuth the new employee information to grant them permissions to PropelAuth. This use case is basically just a webhook where apps provide other apps with realtime information.
However, SCIM can include a lot more than just pushing updates. If you want to see a very clean implementation of SCIM, check out Slack’s documentation.
Single sign on (SSO)
SSO is a term used in different contexts, but the core concept is you should only need to login once and get access to multiple services.
One common example is any site that has “Login with Google” or “Login with Twitter”, etc. on it. When you log in to Google/Twitter/etc, you will get access to any site that supports that login option. This is also called social login, as it’s often implemented with a social networking site like Twitter and Facebook.
Another common example of SSO is SAML, which we talked about above. As an employee of a company, if you log in to your workforce identity system, you will then gain access to any product that your company has set up a SAML connection with.
Take software company Atlassian, which develops different products like Jira, Confluence, Hipchat, etc. While they are built internally and independently from one another within Atlassian, a Jira user wouldn’t need to create a different account to access Hipchat. They would be able to login once to any Atlassian product and get access to any of the other products they pay for.
Open Authorization (OAuth) and OpenID Connect (OIDC)
There’s a large rabbit hole we can dive into on OAuth and OIDC, but to keep things very simple: OAuth helps solve the problem of delegating access to a third party.
If you’ve ever seen a prompt where some application is asking for specific permissions for your twitter account, then you’ve experienced OAuth before:
There’s a variety of different types of OAuth flows for different scenarios (e.g. delegating access to a smart TV has different security concerns than delegating access to a website). Before OAuth existed, the main way to grant access to your account was to share your password. You may remember some old applications that asked for your twitter or bank password and surprisingly… were not a scam.
OIDC is built on top of OAuth, but is used for authentication instead of authorization. OIDC is commonly used in the same situations that SAML is used - allowing customers to log in to a product with their workforce identity accounts.
“Auth” can be pretty complicated. If someone says, “I need you to build SSO support,” you probably need them to clarify exactly what they are envisioning.
One of our initial design goals with PropelAuth was to make it so most people don’t need to worry the details and differences between OAuth, OIDC, SAML, etc. Instead, we securely take care of all of those protocols and provide you with interfaces that allow you to just focus on managing your users and the organizations they are members of.