BACKEND

Home › Glossary › Backend· 44 ·

Authentication vs Authorization

\\aw-then-ti-kay-shuhn ver-suhs aw-thuh-ri-zay-shuhn\\n. phr.

Filed underBackendSecurityApisSoftware Engineering

In brief · quick answer

Authentication verifies who you are. Authorization verifies what you are allowed to do. They are two distinct security concepts that are often confused. Authentication always comes before authorization.

§ 1 Definition

Authentication (AuthN) and Authorization (AuthZ) are the two pillars of access control, and confusing them is one of the most common security mistakes in web development. Authentication answers the question 'Who are you?' It is the process of verifying identity through credentials (password, biometric, security key, OAuth token). Authorization answers the question 'Are you allowed to do this?' It happens after authentication and determines what resources or actions the authenticated identity can access. Authentication is typically handled by login forms, SSO providers, or API keys. Authorization is handled by roles, permissions, policies, access control lists, or attribute-based rules. Most security breaches result from authorization failures, not authentication failures. An attacker who bypasses authorization can access resources using a legitimate authenticated session. Always follow the principle of least privilege: grant only the permissions needed for the task. Both authentication and authorization must be enforced server-side. Client-side checks are cosmetic and trivially bypassed.

§ 2 Authentication Methods

Authentication proves identity. Common methods include: password-based authentication (username + password, verified against a hashed password stored in the database). Multi-factor authentication (MFA) adds a second factor (TOTP app, SMS code, hardware key). Social login and SSO delegate authentication to a trusted provider (Google, GitHub, Okta). Token-based authentication (JWT or opaque bearer tokens) is standard for APIs. Biometric authentication uses fingerprints, facial recognition, or voice. Certificate-based authentication uses client TLS certificates. Stateless protocols like OAuth 2.0 and OpenID Connect provide authentication without the server managing sessions. The choice of method depends on your threat model, user experience requirements, and regulatory compliance needs.

§ 3 Authorization Models

Authorization controls what an authenticated user can do. Common models include: Role-Based Access Control (RBAC), where users are assigned roles (admin, editor, viewer) and roles have permissions. Attribute-Based Access Control (ABAC), where access decisions use attributes (user department, document classification, time of day). Access Control Lists (ACLs) explicitly list who can access each resource. Policy-Based Access Control uses a policy engine (like Open Policy Agent or AWS IAM) to evaluate rules. Relationship-Based Access Control (ReBAC) uses graph relationships (GitHub's 'user X is a collaborator on repo Y'). The right model scales with your application: RBAC works for most applications, ABAC for complex enterprise requirements, and ReBAC for multi-tenant systems.

§ 4 Common Security Mistakes

The most common mistakes are preventable. Failing to check authorization on every API endpoint is the top error. Do not assume that because a user is authenticated, they can access any resource. Checking only in the front-end is useless; any authenticated request can be made via curl. Confusing authentication with authorization leads to roles being used as identity (treating 'admin' as 'who the user is' rather than 'what the user can do'). Overly permissive default roles ('viewer' can edit because the 'viewer' role has edit permissions). Missing server-side checks on WebSocket connections. Always authorize every request server-side, even if the front-end hides the UI elements. Authorization is a server responsibility, not a UI convenience.

§ 5 Note

Common misunderstanding: Logging in (authentication) and getting a token is not the same as authorization. A JWT proves you authenticated. The contents of the JWT (roles, permissions) determine what you are authorized to do. Never trust a JWT claim without verifying it. Another mistake: thinking that hiding a button in the UI is authorization. Authorization must be enforced on the server side. Client-side hiding is cosmetic and trivially bypassed. If a user can send a DELETE request to /api/users/42, your server must check that the user owns or has permission to delete that specific resource.

§ 6 In code

```javascript
// Authentication check
function authenticate(req, res, next) {
  const token = req.headers.authorization?.split(' ')[1];
  if (!token) return res.status(401).json({ error: 'Unauthenticated' });
  
  try {
    req.user = jwt.verify(token, process.env.JWT_SECRET);
    next();
  } catch {
    res.status(401).json({ error: 'Invalid token' });
  }
}

// Authorization check (separate middleware)
function authorize(...allowedRoles) {
  return (req, res, next) => {
    if (!allowedRoles.includes(req.user.role)) {
      return res.status(403).json({ error: 'Forbidden' });
    }
    next();
  };
}

// Usage: both checks, separate layers
router.get('/admin/users', authenticate, authorize('admin'), handler);
```

§ 7 Common questions

Q. Authentication vs Authorization: which comes first?: A. Authentication always comes first. You must know who the user is before you can determine what they are allowed to do.
Q. What happens if authentication succeeds but authorization fails?: A. The server should return 403 Forbidden. The user is identified (authenticated) but does not have permission (authorization) to access the resource.
Q. Do I need both authentication and authorization?: A. Yes, for any application with more than one user. Even a single-user app needs authentication (to confirm it is you) and authorization (to protect your data from cross-account access).

Key takeaways

Authentication (AuthN) verifies identity. Authorization (AuthZ) verifies permissions.
Authentication always precedes authorization. You cannot authorize an unknown user.
Both must be enforced server-side. Client-side checks are cosmetic, not security.
Use RBAC for most applications, ABAC for enterprise, ReBAC for multi-tenant systems.

How Atomic Glue helps

Atomic Glue implements authentication and authorization in every application we build. We use proven patterns: JWT-based authentication with refresh token rotation, RBAC for permission management, and middleware-based authorization guards on every API route. We never compromise on security fundamentals. If your application needs user accounts, roles, and permissions, we build a security model that scales. Auth is a foundational part of our Web Development services. Get in touch to secure your application.

Get in touch

# Authentication vs Authorization

Category: Backend (also: Security, Apis, Software Engineering)

Author: Atomic Glue Development Team

## Definition

## Authentication Methods

## Authorization Models

## Common Security Mistakes

## Note

## In code

## Common questions
Q: Authentication vs Authorization: which comes first?
A: Authentication always comes first. You must know who the user is before you can determine what they are allowed to do.
Q: What happens if authentication succeeds but authorization fails?
A: The server should return 403 Forbidden. The user is identified (authenticated) but does not have permission (authorization) to access the resource.
Q: Do I need both authentication and authorization?
A: Yes, for any application with more than one user. Even a single-user app needs authentication (to confirm it is you) and authorization (to protect your data from cross-account access).

## Key takeaways

Authentication (AuthN) verifies identity. Authorization (AuthZ) verifies permissions.
Authentication always precedes authorization. You cannot authorize an unknown user.
Both must be enforced server-side. Client-side checks are cosmetic, not security.
Use RBAC for most applications, ABAC for enterprise, ReBAC for multi-tenant systems.

## Related entries

Last updated June 2026. Permalink: atomicglue.co/glossary/authentication-vs-authorization-backend