Authentication vs. Authorization

Authentication vs Authorization: What’s the Difference?

The terms authentication and authorization are fundamental to digital identity systems but are often misunderstood or conflated. The distinction is both conceptual and technical, and is enforced by standards and protocols such as LDAP and OAuth.

Authentication is the process of verifying the identity of a user, service, or process. It answers the question, “Who are you?” Common authentication methods include passwords, cryptographic certificates, and challenge-response protocols. In practice, authentication results in the system knowing which identity (if any) is attached to a particular session or request.

Authorization, on the other hand, is the process of determining whether an authenticated entity is permitted to perform a specific action or access certain resources. It answers, “What are you allowed to do?” Authorization relies on policies, rules, or access control lists that associate permissions with identities, roles, or other attributes.

A critical distinction: Authentication must always precede authorization. The system must first establish “who” before it can meaningfully answer “what can be done.” Yet, since these steps often occur in rapid succession, or are handled by different layers of software, confusion is common.

Conceptual Differences at a Glance

Why are the two often confused? Most user-facing applications treat authentication and authorization as a near-simultaneous process (think: log in, then immediately access permitted data), and language like “login” sometimes ambiguously covers both. Many standards and products bundle both controls, but at the protocol and enforcement level, they remain separate (with distinct methods and checks).

How Authentication and Authorization Work Together in Directory Systems

In directory-backed systems—especially those using protocols like LDAP—authentication and authorization are explicitly separated by design and mapped to different protocol operations and server states.

Sequencing in Practice

A canonical LDAP workflow demonstrates the sequencing:

1. LDAP Bind (Authentication):
   The client uses the LDAP Bind operation to present credentials—these may be a password, SASL mechanism, or certificate. Upon success, the server marks the connection as associated with a directory identity. If the Bind is anonymous, no identity is assigned.
2. Operation Request (Authorization):
   After Bind, the client issues requests (e.g., search, read, modify). For each operation, the server checks configured access control lists (ACLs) or policy rules to determine if the authenticated identity is permitted to perform the requested action.
3. Result:
   The outcome of each operation is “allowed” or “denied,” depending solely on the current authentication state and matching authorization rules.

Authentication State and Access Controls in LDAP

• Anonymous Bind: If a client connects with no authentication, the server may permit only restricted, public operations, as dictated by access controls.
• Authenticated Bind: The server applies access controls associated with the bound identity for each operation. For example, even after a successful Bind, the user may have permission to search the directory but not to modify entries, depending on ACL settings.

This explicit flow ensures that authentication is a prerequisite for any meaningful authorization, and that any attempt to bypass authentication (such as an anonymous or unauthenticated Bind) is met with proportionally restricted access.

Modern Authorization Frameworks

Protocols like OAuth reinforce this separation. In the OAuth 2.0 framework:

• Authentication (user verifies with Authorization Server) and authorization (user grants permissions to client, Authorization Server issues tokens) are distinct steps.
• The “resource server” (API endpoint or service) ultimately enforces authorization by validating provided tokens and checking scopes or roles encoded within them.

Practical Examples and Protocol Standards (LDAP, OAuth, API)

LDAP: Protocol Mapping

• Authentication:
  • LDAP “Simple Bind” operation with DN (distinguished name) and password, or SASL exchange.
  • Referenced in [RFC 4513] and [RFC 2829].
• Authorization:
  • On every operation, the LDAP server checks ACLs to see if the bound identity is allowed the requested action (search, read, write, etc.).
  • Fine-grained: Permissions may exist at entry, attribute, or operation level.

Example:
A user performs a Simple Bind to “uid=alice,ou=People,dc=example,dc=com” with a password (authentication). Then, they attempt to search all users. The server checks if “alice” is authorized, via ACLs, to read the “ou=People” subtree.

OAuth 2.0: Explicit Separation

• Authentication:
  • The user authenticates with the Authorization Server, possibly with multi-factor credentials.
• Authorization:
  • The user authorizes specific scopes (“Read contacts,” “Send email”) for a client.
  • The Authorization Server issues access tokens representing these grants.
• Enforcement:
  • When the client presents the access token to a Resource Server (API), the server verifies token validity and attached scopes before responding.

Key point: OAuth access tokens do not prove the user's identity to the resource server—they only express what the token holder is allowed to do. User identity (authentication) is not directly communicated unless an additional protocol (e.g., OpenID Connect with ID Tokens) is layered on top.

Real-World API Patterns

• Many APIs require a bearer token, presenting it in the Authorization header. The API server checks token validity and attached permissions (authorization), but the token itself should carry only the claims needed to enforce access—not serve as an identity proof.
• Authenticating a user does not automatically grant all privileges; each action is individually authorized per policy.

Common Misconceptions (and How Protocols Address Them)

Misconception 1: “OAuth 2.0 is an Authentication Protocol.”

Correction: OAuth 2.0 is an authorization framework (see [RFC 6749]). It enables a resource owner to authorize a client to act on their behalf but does not by itself provide authentication information (e.g., user identity assertions). For authentication, OpenID Connect (OIDC) must be used, which builds directly on OAuth.

Misconception 2: “You Can Authorize Actions Without Authentication.”

Correction: Authorization fundamentally requires knowing whose permissions are being evaluated. Without authentication, any authorization decision is necessarily generic (e.g., only public/anonymous access). LDAP enforces this: anonymous Binds are subject to strict ACLs; sensitive operations require prior authentication.

Misconception 3: “Authentication and Authorization Always Use the Same Protocol or System.”

Correction:
LDAP illustrates clean separation: Bind (authentication) vs. operation-level ACL checks (authorization). Similarly, an application may rely on Kerberos for authentication but have its own internal authorization engine.

Misconception 4: “An Access Token Serves as Proof of User Identity.”

Correction: In OAuth, access tokens indicate what actions the client is permitted to perform, not who the end-user is. Relying only on possession of an access token for identity is insecure and prohibited by best practice and standards.

Directory Technology Nuances

• Anonymous LDAP binds are valid per protocol, but only permit access explicitly granted via “anonymous” ACLs—never privileged operations.
• Fine-grained LDAP ACLs can control access per attribute, entry, or operation, allowing complex authorization decisions beyond simple user-role checks.
• Token and session invalidation: In all protocols, authentication and authorization states can be revoked or expire. Both must be checked on each relevant action rather than assumed persistent.

Key Takeaways: Authentication vs Authorization Summary

At-a-Glance Table

Conceptual Diagram

[User/Client]
    │
   (Authenticate: Password/Credentials/Bind/OIDC, etc.)
    │
    ├──> [Authenticated Identity Established]
                │
        (Authorize: Check ACLs/Roles/Scopes/Policies)
                │
         └─> [Action Allowed or Denied]

Sources

• www.rfc-editor.org — rfc4513
• datatracker.ietf.org — rfc4962
• datatracker.ietf.org — rfc6749
• datatracker.ietf.org — rfc7617
• datatracker.ietf.org — rfc2829
• datatracker.ietf.org — rfc9200