July 19, 2026 Security, identity, architecture

Authentication, Authorization, and Identity: They're Not the Same Thing

Identity systems are the foundation of modern applications. Explore how identity, authentication, authorization, sessions, OAuth 2.0, OpenID Connect, SAML, JWTs, RBAC, and ABAC work together and the architecture mistakes teams make when these concepts are misunderstood.

Authentication, Authorization, and Identity: They’re Not the Same Thing

In many software systems, identity, authentication, and authorization are treated as interchangeable concepts.

A user logs in, receives a token, accesses an API, and everything appears to work. Over time, however, these boundaries become blurred. Identity data gets mixed with authentication logic. Authorization rules get embedded inside applications. Tokens become overloaded with permissions. Service accounts become unmanaged users.

These decisions might work for a small application, but they create significant architectural challenges as systems grow.

Modern SaaS platforms are built around identity systems that separate who someone is, how they prove it, and what they are allowed to do.

Understanding these boundaries is fundamental to designing scalable platforms.

Identity: Who Are You?

Identity represents an entity inside a system.

That entity could be:

  • A human user
  • A customer organization
  • An employee
  • A service
  • A device
  • A workload running in the cloud

Identity is the representation of something that interacts with a system.

For example, in a SaaS product, identity is not just an email address. A typical identity model includes:

  • User ID
  • Email
  • Organization
  • Role
  • Groups
  • Attributes
  • Authentication methods

The same person can have different identities across different systems:

  • A corporate identity in an enterprise directory
  • A GitHub identity for development
  • A cloud identity for infrastructure access
  • A customer identity in a SaaS application

Identity systems answer: “What entity is this?”
They do not answer: “Can this entity access this resource?” — that is authorization.

Authentication: Proving Identity

Authentication answers: “Can you prove that you are this identity?”

Authentication mechanisms verify identity claims. Common methods include:

  • Passwords
  • Multi-factor authentication
  • Hardware security keys
  • Certificates
  • OAuth flows
  • SSO providers

For example, when an employee logs into a corporate system, the platform verifies:

  • The user exists
  • The credentials are valid
  • Additional authentication requirements are satisfied

After successful authentication, the system creates a trusted session or issues tokens.

Authentication establishes identity. It does not determine permissions.

A common architecture mistake is assuming: Authenticated user = Authorized user.

This is incorrect. A successfully authenticated employee may still not have permission to access:

  • Production databases
  • Financial reports
  • Customer data
  • Administrative functions

Authentication says: “This is Alice.”
Authorization says: “Alice can access these resources.”

Authorization: What Can You Do?

Authorization determines permissions. It answers: “Given this identity, what actions are allowed?”

Examples:

  • Read customer records
  • Create projects
  • Delete their own files
  • Manage billing

Another user might have:

  • Read-only access
  • No administrative privileges

Authorization happens after authentication. A simplified flow:

User
   |
   | Authentication
   v
Identity Provider
   |
   | Identity Token
   v
Application
   |
   | Authorization Check
   v
Resource Access

Many systems fail because authorization logic is scattered throughout applications. For example:

if user.role == "admin":
    allow_delete()

This works initially. But as organizations grow:

  • Roles multiply
  • Exceptions appear
  • Customers require custom permissions
  • Compliance requirements increase

Authorization becomes difficult to manage.

Session Management: Maintaining Trust

Authentication is usually a short event. Sessions maintain that authentication state.

A session answers: “Has this user already proven their identity?”

Without sessions, users would authenticate for every request.

A typical web flow:

  1. Login
  2. Authentication Provider
  3. Session Created
  4. Browser sends Session Cookie
  5. Application validates session

Modern SaaS applications commonly use:

  • Secure cookies
  • Session databases
  • Access tokens
  • Refresh tokens

A common mistake is treating tokens as permanent identity. Tokens represent a temporary authorization context. They should have:

  • Expiration
  • Limited scope
  • Revocation mechanisms
  • Audience restrictions

Machine Identities: Humans Are Not the Only Users

Modern systems contain more machines than humans. Examples:

  • Microservices
  • CI/CD pipelines
  • Cloud workloads
  • Automated jobs
  • IoT devices

These require identities too. For example, a Kubernetes service might need access to:

  • A database
  • Object storage
  • Another API

Creating a normal user account for this is a mistake. Instead, systems use machine identities.

Cloud platforms such as AWS and Google Cloud provide workload identity systems where applications authenticate without storing static passwords.

Principle: Applications should authenticate as themselves, not as users.

OAuth 2.0: Delegated Authorization

OAuth 2.0 is one of the most misunderstood identity protocols. OAuth is not authentication. It answers: “Can this application access resources on behalf of this user?”

Example: A user connects a SaaS application to their Google account. Instead of giving the application their password:

  • User grants permission
  • Google issues an access token
  • Application uses the token to access specific resources

OAuth provides delegated access. It does not tell the application who the user is. That’s where OpenID Connect comes in.

OpenID Connect: Authentication Layer on OAuth

OpenID Connect (OIDC) extends OAuth 2.0 to provide authentication. OAuth asks: “Can this application access something?” OIDC asks: “Who is the user?”

OIDC introduces the ID token, which contains identity claims:

{
  "sub": "123456",
  "email": "[email protected]",
  "name": "Alice"
}

Modern SaaS applications commonly use OIDC for:

  • Enterprise SSO
  • Social login
  • Workforce authentication

Examples include:

  • “Sign in with Google”
  • “Login with Microsoft”
  • Enterprise SSO portals

SAML: Enterprise Identity Federation

Before OIDC became common, enterprises heavily relied on SAML. SAML allows an identity provider to authenticate users for another application.

Example flow:

  • Employee logs in via corporate identity provider
  • Identity provider issues a SAML assertion
  • SaaS application consumes the assertion

Large organizations often use SAML with CRM platforms, HR systems, and enterprise SaaS tools. While OIDC is preferred for modern applications, SAML remains important in enterprise environments.

JWTs: Tokens, Not Identity

JSON Web Tokens (JWTs) are often misunderstood. A JWT is simply a token format. It contains claims:

{
  "sub": "user123",
  "role": "admin",
  "exp": 1780000000
}

JWTs are useful because services can validate them without calling another system. Example:

Client
   |
   JWT
   |
API Gateway
   |
Backend Service

However, JWTs introduce architectural decisions:

  • Token Lifetime: Long-lived tokens create security problems.
  • Token Size: Adding every permission into a JWT creates oversized tokens.
  • Revocation: Unlike server-side sessions, JWT revocation is harder.

A common mistake: stuffing every possible permission into a JWT. Instead, use JWTs as identity carriers and perform authorization checks separately.

API Authentication

APIs require authentication too. Common approaches:

  • API Keys: Simple, but limited in attribution and expiration.
  • OAuth Access Tokens: Standard for SaaS integrations and mobile apps.
  • Mutual TLS: Strong machine identity, common in finance and high-security environments.

RBAC: Role-Based Access Control

RBAC assigns permissions based on roles. Example:

  • Admin: Create users, delete projects
  • Developer: Deploy applications
  • Viewer: Read dashboards

RBAC works well when permissions map naturally to organizational roles. Examples: GitHub repositories, cloud consoles, enterprise apps. But RBAC becomes difficult when exceptions grow.

ABAC: Attribute-Based Access Control

ABAC makes authorization decisions using attributes. Instead of “User has role Admin,” ABAC evaluates:

  • User attributes
  • Resource attributes
  • Context

Example: Allow access when:

  • User.department == "Finance"
  • Resource.region == "EU"
  • Request.time during business hours

ABAC is powerful for complex organizations like healthcare systems, financial platforms, and multi-tenant SaaS products.

Common Identity Architecture Mistakes

  • Mixing authentication and authorization
  • Treating roles as permissions
  • Using user accounts for services instead of machine identities
  • Putting authorization logic everywhere instead of centralizing

Identity as an Architecture Foundation

Modern applications are identity-driven systems. A mature identity architecture separates:

  • Identity
  • Authentication
  • Session / Tokens
  • Authorization
  • Resource Access

Protocols like OAuth 2.0, OpenID Connect, and SAML solve different problems. JWTs provide a token format. RBAC and ABAC provide authorization models.

Understanding these boundaries allows organizations to build SaaS platforms that scale from a few users to millions of identities without turning access control into an architectural bottleneck.

Identity is no longer just a login system. It is the foundation that determines how every user, service, and application interacts with the modern software ecosystem.