Information Security Learning Resources

Information security is a broad field, but authentication and authorization are especially close to everyday application

Information security is a broad field, but authentication and authorization are especially close to everyday application behavior. They determine whether a user is who they claim to be and whether that user is allowed to perform a particular action. Failures in these areas can expose sensitive data, enable administrative actions, and undermine trust in an entire system. A useful learning path therefore begins with clear concepts, moves through protocols and access models, and ends with practical experimentation in controlled labs.
Authentication answers the question, “Who is making this request?” It validates evidence such as a password, passkey, one-time code, or hardware-backed credential. A successful authentication process establishes the identity of a principal, which may be a person, service, device, or application.

Authorization answers a different question: “What may this principal do?” It evaluates permissions against a requested action and resource. For example, authentication might confirm that a customer owns an account, while authorization must still determine whether that customer can view, modify, or cancel a specific order.

The distinction matters because successful login does not imply correct permissions. An authenticated user who changes an order identifier in a request may perform an unauthorized action. This class of weakness is commonly described as broken object-level authorization or broken function-level authorization.

A typical request follows three stages:

  1. The system identifies the principal through a session or token.
  2. It evaluates the requested operation against access-control rules.
  3. It records or monitors the decision when audit requirements apply.

Access control is the broader umbrella that includes these authorization decisions and their enforcement. It should also cover restrictions on direct object references, administrative privileges, tenant boundaries, and the ability to elevate permissions.

A Map of the Core Topics

The subject can be organized into three interconnected areas:

Area Main question Representative concepts
Identity and delegation protocols How can one system establish and delegate trust? OAuth 2.0, OpenID Connect, SAML
Authorization models How are access decisions expressed? ACL, RBAC, ABAC
Credentials, sessions, and tokens How is authenticated state carried between requests? Cookies, session IDs, bearer tokens, JWTs

These areas solve different problems, but they must work together. A protocol may describe how a client obtains delegated access, while an authorization model determines what access should be granted. Cookies, sessions, and tokens then provide the mechanisms used to carry the resulting state through HTTP requests.

Protocols

OAuth 2.0 is an authorization framework for delegating scoped access to protected resources. It should not automatically be treated as a user-authentication protocol. When OAuth is combined with OpenID Connect, an OpenID Provider can also issue identity information about the end user.

SAML is an XML-based framework for exchanging authentication and authorization assertions between identity providers and service providers. It remains common in enterprise environments.

When comparing these protocols, focus on their trust relationships, client types, token formats, redirect behavior, and threat models—not merely on their sequence diagrams.

Authorization Models

  • Access Control Lists (ACLs) associate permissions directly with users or resources. They are straightforward and effective for small, finely managed permission sets.
  • Role-Based Access Control (RBAC) groups permissions into roles and assigns roles to principals. It simplifies administration in systems with stable job functions.
  • Attribute-Based Access Control (ABAC) evaluates relationships among subject attributes, resource attributes, actions, and environmental conditions. It offers flexible policy decisions but requires stronger design and testing discipline.

No model is universally superior. A small internal tool may be well served by ACLs, while a multi-tenant platform may combine RBAC for coarse-grained administration with ABAC for contextual decisions.

Cookies, Sessions, and Tokens

A session stores authenticated state between requests. In a conventional server-side session design, the browser receives an opaque session identifier, commonly in a cookie, and the server looks up the associated state.

A cookie is a client-side storage and transmission mechanism, not an authorization model. Sensitive session cookies should normally use attributes such as Secure, HttpOnly, and an appropriate SameSite policy.

A JSON Web Token (JWT) is a compact, signed set of claims. A relying party must verify its signature and expected fields such as iss, aud, and exp. JWTs are not encrypted by default, and their self-contained nature does not eliminate risks such as theft, excessive lifetime, weak key management, or missing revocation.

A Structured Learning Path

1. Build the Foundations

Start with HTTP’s stateless request model, browser security, TLS, and the difference between identity and permission. Learn how passwords, multi-factor authentication, passkeys, cookies, sessions, and tokens behave. Understanding these fundamentals makes later protocol and framework material much easier to interpret.

2. Study the Main Protocols

Read the core flows of OAuth 2.0 and OpenID Connect. Pay particular attention to roles, scopes, redirects, authorization codes, refresh tokens, state, and PKCE. Learn why a browser should not receive a long-lived authorization credential merely to complete a login.

Next, examine SAML assertions and trust metadata. Rather than memorizing every field, identify who signs each message, how recipients establish trust, and where time synchronization and audience validation matter.

3. Design an Authorization Model

Create a small application with users, roles, resources, and ownership rules. Implement a simple ACL, then redesign it using RBAC. Add attributes such as department, location, device trust, or risk level and introduce ABAC.

Document every decision in plain language. For example:

A user may update an invoice when the invoice belongs to the user’s organization, the invoice is still editable, and the user has the invoice.update permission.

Such statements expose ambiguous rules that are difficult to implement or audit.

4. Practice Attacks and Defenses

In a legal lab environment, reproduce common weaknesses and then implement the corresponding controls:

  • Broken access control: Modify object identifiers or call restricted functions directly.
  • Session fixation: Observe how session identifiers behave before and after authentication.
  • CSRF: Test whether state-changing requests depend on ambient browser credentials.
  • Session theft: Examine the impact of missing cookie flags, insecure transport, or excessive session lifetime.
  • Token misuse: Explore scope confusion, redirect manipulation, replay, and insufficient token validation.
  • JWT errors: Test missing signature checks, incorrect algorithms, absent audiences, and expired claims.

The objective is not merely to make a payload work. It is to understand which trust boundary failed and how the design can be made safer.

Specifications and Authoritative Guidance

Books

  • OAuth 2 in Action — A practical explanation of OAuth architecture, implementation choices, and common pitfalls.
  • API Security in Action — Covers API design, token handling, rate limiting, authorization, and operational security.
  • The Web Application Hacker’s Handbook — A broad guide to web vulnerabilities and the reasoning required to test defenses systematically.

Courses and Practice Platforms

How to Study Effectively

  • Learn principles before frameworks. Framework configuration is easier to reason about once the underlying trust model is clear.
  • Compare related concepts. Place sessions beside tokens, RBAC beside ABAC, and OAuth beside OpenID Connect. The trade-offs are more memorable than isolated definitions.
  • Use attacks to deepen defense. A controlled demonstration of an access-control flaw often reveals design weaknesses that checklist review would miss.
  • Return to primary sources. Tutorials can simplify important details or become outdated. Verify protocol behavior and security claims against current specifications.
  • Keep a decision log. Record assumptions, threats, validation steps, and rejected alternatives. This turns implementation details into reusable knowledge.
  • Test negative cases as well as successful ones. Include expired sessions, revoked roles, cross-tenant requests, altered identifiers, missing claims, and unauthorized methods.

A strong information-security learning program develops two connected capabilities: the ability to establish trustworthy identity, and the ability to maintain controlled access. Protocols explain how trust is exchanged, authorization models explain how decisions are made, and sessions and tokens explain how state travels. Once those three layers are understood, hands-on labs and authoritative documentation can turn conceptual knowledge into practical security judgment.