Modern Authentication & Authorization: OAuth 2.0, JWT, and Beyond

Authentication (who are you?) and authorisation (what can you do?) are foundational security concerns.

Yet many applications implement them poorly, creating vulnerabilities that affect every user.

The good news: modern authentication standards (OAuth 2.0, OpenID Connect) and token-based approaches (JWT) are well-established and relatively straightforward to implement correctly.

Authentication vs Authorisation

These terms are often confused but are distinct concepts:

• Authentication: verifying the user is who they claim to be (usually via credentials)
• Authorisation: verifying the user has permission to perform the requested action

Example: you authenticate via username/password. Once authenticated, the system determines (via authorisation checks) whether you can view other users' data, modify settings, delete resources, etc.

Authentication happens once at login. Authorisation happens on every action.

Traditional Approach: Sessions and Cookies

Historically, authentication worked via server-side sessions:

• User provides username/password
• Server verifies credentials and creates a session
• Session is stored on the server and referenced by a session ID
• Session ID is sent to the browser as a cookie
• Browser automatically includes the cookie on every request
• Server looks up the session to determine who the user is

This approach works but has limitations:

• Scalability: session storage requires a shared database or cache across all servers
• Mobile apps: cookies work in browsers but not in mobile apps (though still possible)
• Third-party access: difficult to grant third-party apps access without sharing passwords
• CSRF vulnerabilities: sessions are susceptible to cross-site request forgery attacks

Modern Approach: OAuth 2.0

OAuth 2.0 is the industry standard for delegated access. It separates the identity provider from the application.

Flow example (user logging into your app via Google):

• User clicks 'Login with Google'
• Your app redirects to Google's login page
• User authenticates to Google (if not already logged in)
• Google asks user: does your-app get permission to access your email and profile?
• User grants permission
• Google redirects back to your app with an authorisation code
• Your app exchanges the code for tokens (access token, refresh token, ID token)
• Your app uses the access token to make requests on behalf of the user

Key advantage: your application never sees the user's Google password. Google handles authentication; your app handles authorisation.

JWT (JSON Web Tokens)

JWT is a popular token format for authentication/authorisation. A JWT contains information about the user and is cryptographically signed.

Structure: Header.Payload.Signature

• Header: metadata about the token
• Payload: claims (assertions about the user) — ID, email, roles, etc.
• Signature: proves the token wasn't tampered with

Advantages:

• Stateless: the server doesn't store anything; tokens are self-contained
• Mobile-friendly: easily passed in HTTP headers or local storage
• Scalable: no shared session storage needed
• Works across domains and services

Disadvantages:

• Tokens are relatively large compared to session IDs
• Revocation is difficult (if a token is issued for 1 hour, you can't instantly revoke it)
• Prone to misuse if not careful about token expiration and refresh tokens

JWT Best Practices

If using JWT:

• Short expiration: access tokens should expire quickly (15-60 minutes). Use a longer-lived refresh token to obtain new access tokens.
• Sign with HMAC or RS256: HMAC uses a shared secret; RS256 uses asymmetric cryptography. For multi-service systems, RS256 is better.
• Don't store secrets in the token: if a field should be secret, store it on the server, not in the token
• Validate the signature: always verify the token signature before trusting the claims
• Validate expiration: ensure the token hasn't expired
• Use HTTPS: tokens can be intercepted in transit; HTTPS prevents this
• Refresh tokens securely: refresh tokens should be stored securely (httpOnly cookies are ideal)

Multi-Factor Authentication (MFA)

Passwords are the weakest link in authentication. MFA adds a second factor, dramatically improving security.

Types of second factors:

• Time-based One-Time Password (TOTP): authenticator app (Google Authenticator, Authy) generates codes. Industry standard.
• SMS: text message containing a code (less secure than TOTP but more accessible)
• Email: confirmation code sent to registered email
• Hardware keys: physical security keys (YubiKey, etc.) — most secure
• Biometric: fingerprint or face recognition (most accessible but device-dependent)

For high-security applications (financial, healthcare, government), MFA should be mandatory. For others, it should be optional but encouraged.

Role-Based Access Control (RBAC)

Authorisation determines what authenticated users can do.

Role-Based Access Control (RBAC) is the most common approach:

• Define roles: Admin, Editor, Viewer, etc.
• Assign permissions to roles: Admins can create/edit/delete; Editors can create/edit; Viewers can only read
• Assign users to roles: John is an Admin, Jane is an Editor
• Check roles on every action: before serving a request, verify the user has the required role

Simplicity is the advantage. The disadvantage: role hierarchies can become complex.

Attribute-Based Access Control (ABAC)

For more complex scenarios, Attribute-Based Access Control uses attributes of the user, resource, and context to make decisions.

Example: 'Users can only edit documents they created, within their department, during business hours.'

This requires more sophisticated policy evaluation but provides fine-grained control.

Common Authentication Pitfalls

• Storing plaintext passwords: always hash passwords. Use bcrypt, scrypt, or Argon2 (modern algorithms that are slow to compute, making brute force attacks impractical)
• Weak password requirements: passwords should be long, not just complex (length matters more than special characters)
• No rate limiting on login attempts: without rate limiting, attackers can brute force passwords. Limit login attempts per IP.
• Storing tokens in local storage: tokens in localStorage are accessible via JavaScript/XSS. httpOnly cookies are more secure.
• Not validating token signatures: trusting a JWT without verifying the signature is equivalent to trusting any token someone gives you
• Long token expiration: if a token is valid for a year, stolen tokens represent a year of risk. Keep expiration short.
• Mixing authentication and authorisation: sometimes developers check 'is the user logged in?' when they should check 'does the user have permission for this action?'

Social Login vs Traditional

Social login (Google, GitHub, Microsoft) is increasingly popular. Advantages:

• Users don't need to remember another password
• You delegate authentication to a trusted provider
• You get additional information about the user (email, profile picture, etc.)

Disadvantages:

• You depend on third-party availability
• You must trust the provider with user data
• Some users distrust giving apps access to their social accounts

Best practice: offer both social login and traditional login. Let users choose.

Implementing Securely

Checklist for secure authentication/authorisation:

• Passwords hashed with bcrypt/scrypt/Argon2
• HTTPS for all auth traffic
• Rate limiting on login, password reset, and other sensitive endpoints
• Short-lived tokens (access tokens expire in 15-60 minutes)
• Refresh tokens stored securely (httpOnly cookies)
• MFA available (optional or mandatory depending on risk profile)
• CORS configured correctly (only allow expected origins)
• CSRF protection if using cookies
• Tokens/sessions invalidated on logout
• Audit logging of auth events (successful logins, failed attempts, permission changes)

The Bottom Line

Authentication and authorisation are security fundamentals. Get them right: use OAuth 2.0 for third-party access, JWT for stateless auth, secure password storage, and MFA for high-security applications.

Don't build custom solutions. Use well-tested libraries and services. The attack surface of auth is broad; established solutions have undergone security review.

Most breaches involve compromised credentials. Invest in strong authentication; it's one of the highest-impact security measures.