Authentication, Authorization, Single Sign-On, & Federated Identity Explained

Identity and access management (IAM) is a major part of day-to-day enterprise workflows, and with that often comes confusion around authentication, authorization, single sign-on, and federated identity. Let’s break each down in simple terms, which also apply to consumer workflows in addition professional environments.

Authentication (AuthN) vs. Authorization (AuthZ)

Authentication is confirming a user is who they say they are, when logging-in to an account, service, website, application, etc.

The most common and traditional form of authentication is the username/password combination, although other forms of authentication include one-time passwords, multi-factor authentication, single sign-on, and biometrics (like a fingerprint or facial recognition).

Any time you access some form of account, user, etc., you’re authenticating in some form or another. However, authenticating doesn’t grant you access to resources; that’s where authorization comes into play (once authentication is complete).

You may have heard of OpenID Connect before, which is a good example of an identity authentication component (layered on top of OAuth 2.0, which handles authorization).

Authorization is what determines which resources an authenticated user has access to. For example, when you log-in to your bank account (authenticate) you can only see certain accounts (i.e. the ones that belong to you). In other words, you’re only authorized to access those accounts and not the accounts of other users.

A more common example from an enterprise environment is when you connect to a file server, but can only access certain shares, folders, and files. First you log-in to a user on your computer (authenticate), and then access specific resources (only what you’re authorized to access).

Authorization can also involve granting other applications rights to your account’s information. For example, you can authorize an app to read your Google Calendar but not modify it. Your logged-in Google identity has already been authenticated, and now you’re authorizing an application, service, website, etc. to have various levels of access to your account information (in this case your Google Calendar).

A good example of an authorization protocol is OAuth 2.0, which the aforementioned OpenID Connect is built on top of.

OAuth and OpenID are popular with websites, web applications, and smartphone apps, however an older standard, Security Assertion Markup Language (SAML), is still common for federated identity services in enterprises.

Single Sign-on (SSO) vs. Federated Identity Management (FIM)

Single sign-on (SSO) is what allows a single digital identity, let’s say your Google account, to access multiple Google services without needing a separate account for each. As a working example you can log-in to your Gmail (which authenticates your Google account, i.e. your single sign-on), then open Google Drive and continue using that same identity (your Google account) for Google Drive access without logging-in again.

Gmail and Google Drive are technically separate services, but since your Google account provides single sign-on you can use the single digital identity to authenticate to both.

The same concept can be applied to an enterprise environment, where Microsoft’s Active Directory allows users to sign-in once but then access the many resources and services that they’re (potentially) authorized to in that domain.

Federation is related to single sign-on, however while SSO allows a single identity to be used for authentication throughout an organization (think the suite of Google services: Gmail, YouTube, Drive, Calendar, etc.), federation allows for that same functionality spanning multiple organizations, domains, or services.

While SSO is a function of federation, using SSO doesn’t necessarily mean that federation is being used.

For federation, think of using your Google account to sign-in to LinkedIn, or logging-in to Spotify using your Facebook account. Those services are part of separate organizations, however you’re still able to use a single identity to log-in to both (Google/LinkedIn, or Facebook/Spotify) due to federation.

Finally, two common terms you’ll hear surrounding SSO and federation are Identity Provider (IdP) and Service Provider. Identity Providers store digital identities and can authenticate users, while Service Providers request authentication from Identity Providers and provide services to authenticated users. When you log-in to Spotify using your Facebook account, Facebook is the Identity Provider and Spotify is the Service Provider.

Stealthbits Technologies

IDENTIFY THREATS. SECURE DATA. REDUCE RISK.

Stealthbits Technologies, Inc. is a customer-driven cybersecurity software company focused on protecting an organization’s sensitive data and the credentials attackers use to steal that data. By removing inappropriate data access, enforcing security policy, and detecting advanced threats, our highly innovative and infinitely flexible platform delivers real protection that reduces security risk, fulfills compliance requirements, and decreases operational expense.

For more information, please visit stealthbits.com.