Authentication & Authorization

---

In this blog, we’ll unpack how to design strong, scalable authentication & authorization systems using OAuth2, OIDC, RBAC, and ABAC, while aligning with the OWASP ASVS to prevent common security flaws.

Authentication vs Authorization: Know the Difference

While authentication confirms who a user is, authorization defines what they're allowed to do.

Get this wrong, and attackers might act as admins—or regular users may see sensitive data.

---

Secure Identity Patterns: OAuth2, OIDC, RBAC, ABAC

OAuth 2.0 – Delegated Authorization

OAuth2 allows applications to access APIs on a user’s behalf without storing passwords.

Typical Flow:

1. User authenticates via an Identity Provider (IdP)

2. The IdP returns an access token

3. The client app uses the token to call protected APIs

Example: A user logs into a photo editing application (client app) and grants it permission to access their photos stored on Google Photos (resource server) through Google (IdP). The photo editing app receives an access token and uses it to retrieve photos without ever seeing the user's Google password.

Use short-lived access tokens and refresh tokens to maintain security and user experience.

---

OpenID Connect (OIDC) – Add Authentication on Top

OIDC extends OAuth2 with identity features:

• Issues an ID token (JWT) containing claims like sub, email, name

• Perfect for Single Sign-On (SSO)

Use OIDC when your app needs to know who the user is and validate sessions.

Example: A user signs into a new e-commerce website using their existing Google account. OIDC allows the e-commerce site to verify the user's identity (e.g., their name and email) from Google, enabling a seamless sign-up and login experience

---

RBAC – Role-Based Access Control

The simplest and most common authorization model:

• Users get roles (e.g., admin, editor, viewer)

• Roles define access to resources and actions

jsonCopyEdit{
  "user": "alice",
  "roles": ["admin"]
}

Pros: Easy to implement
Cons: Lacks flexibility—permissions are fixed

Example: In a content management system, users can be assigned "Editor" or "Viewer" roles. An "Editor" can create, edit, and publish articles, while a "Viewer" can only read published articles.

---

ABAC – Attribute-Based Access Control

ABAC uses dynamic rules based on user, resource, and contextual attributes.

Example Policy:

Allow access if user.department == resource.department and user.level >= 3

Pros: Granular, flexible
Cons: Needs a policy engine (e.g., OPA, Cedar)

Example: An ABAC policy in a healthcare system might state: "A doctor (user role) can view patient records (resource) if the patient is assigned to their department (resource attribute) and the doctor has a valid medical license (user attribute) and the access request is made during business hours (contextual attribute)."

---

Common ASVS Flaws in Authentication & Authorization

The OWASP Application Security Verification Standard (ASVS) defines security requirements for software.

Here’s how to mitigate auth-related flaws across key ASVS sections:

---

ASVS V2 – Authentication Controls

---

ASVS V3 – Session Management

---

ASVS V4 – Access Control

---

How to Enforce Auth Across the SDLC

---

Secure Implementation Patterns

• Store tokens securely (e.g., HTTP-only cookies)

• Validate JWT claims: iss, aud, exp, scope

• Centralize policy checks (middleware or gateways)

• Use libraries: passport.js, Spring Security, Auth0 SDKs, OPA

---

Tools of the Trade

---

Final Takeaways

• Use OIDC for identity, OAuth2 for delegation

• Start with RBAC, scale to ABAC for fine-grained control

• Map authentication and access logic to ASVS requirements

• Treat tokens like passwords: secure them, rotate them, expire them

• Use threat modeling + automation to catch logic flaws before attackers do

---