Deepak Gupta

Identity: The Foundation Most People Skip

The Number That Should Change How You Think About Security

Here is the number to know. In Verizon's 2025 Data Breach Investigations Report, credential abuse was the most common way attackers got in, at 22% of breaches. In the 2026 report, exploiting software flaws took the top spot (31%), but stolen credentials stayed near the top. Phishing, help-desk social engineering and session-token theft are identity attacks too.

You may see a much bigger "88%" figure quoted online. In the DBIR, that number applies only to one attack pattern (basic web application attacks), not to all breaches. Learn to check which slice of the data a statistic describes. It is a habit that will serve you throughout your career.

Think about what the real numbers mean. If you do not deeply understand identity (how authentication works, why authorization fails, what makes credential systems vulnerable), you are ignoring one of the top two ways attackers get in.

I did not stumble into identity security by accident. I founded LoginRadius in 2013, a customer identity and access management (CIAM) platform that scaled to serve more than a billion users. I spent years thinking about nothing but how to authenticate people securely, how to manage sessions, how to implement social login without creating security holes, how to handle passwords at scale, and eventually how to move beyond passwords entirely.

What I learned through that experience is that identity is the most underappreciated domain in cybersecurity. It is not glamorous. It does not make for exciting conference talks compared to zero-day exploits or advanced persistent threats. But it is where the vast majority of actual damage happens, and it is where the career opportunities are richest.

Identity Basics: What Everyone Needs to Know

Let us start with the fundamentals that every security professional must understand, regardless of specialization.

Authentication vs. Authorization

These two concepts are the foundation of everything in identity security, and people confuse them constantly.

Concept	Question It Answers	Example	Analogy
Authentication (AuthN)	"Who are you?"	Logging in with username/password	Showing your ID at the door
Authorization (AuthZ)	"What are you allowed to do?"	Can this user access the admin panel?	Your ID says you are over 21, so you can buy alcohol

Authentication always comes first. You have to establish who someone is before you can determine what they should be allowed to do. But many systems get this wrong. They authenticate properly but then fail to check authorization correctly, leading to vulnerabilities like broken access control, the #1 category in the OWASP Top 10.

The Identity Stack

Here is how the major identity concepts fit together:

    THE IDENTITY STACK
    ==================

    +--------------------------------------------------+
    |                   APPLICATIONS                    |
    |   Web Apps | Mobile Apps | APIs | Microservices   |
    +--------------------------------------------------+
         |              |              |
         v              v              v
    +--------------------------------------------------+
    |              AUTHORIZATION LAYER                  |
    |   RBAC | ABAC | Policies | Permissions | Scopes  |
    +--------------------------------------------------+
         |
         v
    +--------------------------------------------------+
    |              AUTHENTICATION LAYER                 |
    |   Passwords | MFA | Passkeys | Biometrics | SSO  |
    +--------------------------------------------------+
         |
         v
    +--------------------------------------------------+
    |              IDENTITY PROVIDER (IdP)              |
    |   User Store | Profile Mgmt | Session Mgmt       |
    |   Okta | Entra ID | Auth0 | LoginRadius          |
    +--------------------------------------------------+
         |
         v
    +--------------------------------------------------+
    |              DIRECTORY / USER STORE               |
    |   Active Directory | LDAP | Cloud Directory       |
    +--------------------------------------------------+

IAM vs. CIAM

This distinction matters more than most people realize, and it is core to understanding the identity market.

Aspect	IAM (Workforce Identity)	CIAM (Customer Identity)
Who are the users?	Employees, contractors, partners	Customers, end users, consumers
Scale	Thousands to hundreds of thousands	Millions to billions
Primary concern	Security and compliance	User experience AND security
Registration	IT provisions accounts	Self-service sign-up
MFA tolerance	High (employer mandates it)	Low (customers will leave)
Data privacy	Internal policies	GDPR, CCPA, regulatory compliance
Examples	Okta, Microsoft Entra ID, Ping Identity	LoginRadius, Auth0, Amazon Cognito
Performance needs	Moderate	Very high (consumer traffic spikes)

When I built LoginRadius, the core challenge was this tension between security and user experience. With workforce IAM, you can force employees to use complex passwords, hardware tokens, and lengthy enrollment processes. With CIAM, if you make login too difficult, your customers leave. Every friction point in authentication costs real revenue. Learning to balance security with usability is one of the most valuable skills in identity security.

How Authentication Actually Works

Let me walk you through what happens when you click "Log In" on a website. This is knowledge that surprisingly few security professionals have at a deep level.

Password-Based Authentication Flow

    PASSWORD AUTHENTICATION FLOW
    ============================

    User                    Application              Database
     |                         |                        |
     |  1. Enter user/pass     |                        |
     | ----------------------> |                        |
     |                         |  2. Hash password      |
     |                         |     hash(pass + salt)  |
     |                         |                        |
     |                         |  3. Compare hash to    |
     |                         |     stored hash        |
     |                         | ---------------------> |
     |                         |  4. Match/No match     |
     |                         | <--------------------- |
     |                         |                        |
     |                         |  5. Generate session   |
     |                         |     token (if match)   |
     |                         |                        |
     |  6. Set session cookie  |                        |
     | <---------------------- |                        |
     |                         |                        |
     |  7. Subsequent requests |                        |
     |     include cookie      |                        |
     | ----------------------> |                        |
     |                         |  8. Validate session   |
     |                         | ---------------------> |

Key security principles in this flow:

Never store plaintext passwords. Store the hash. If an attacker steals the database, they get hashes, not passwords. Modern systems use bcrypt, scrypt, or Argon2 for hashing.
Use a unique salt per password. A salt is random data added to the password before hashing. This prevents attackers from using precomputed rainbow tables.
Session tokens must be unpredictable. If an attacker can guess or forge a session token, they can hijack the user's session without knowing the password.
Transmit credentials only over HTTPS. If the connection is not encrypted, anyone on the network can see the password in transit.

Multi-Factor Authentication (MFA)

MFA requires users to prove their identity with at least two different types of factors:

Factor Type	What It Is	Examples	Strength
Something You Know	Information only the user should know	Password, PIN, security question	Weakest: can be stolen, guessed, or phished
Something You Have	A physical device the user possesses	Phone (SMS/app), hardware key, smart card	Strong: requires physical access
Something You Are	Biometric characteristics	Fingerprint, face, iris, voice	Strong: hard to replicate

Warning

Not all MFA is created equal. SMS-based MFA (text messages) is significantly weaker than app-based (TOTP) or hardware key (FIDO2) MFA. SIM swapping attacks can intercept SMS codes, and SS7 protocol vulnerabilities can redirect text messages. If you are recommending MFA to an organization, push for phishing-resistant methods like FIDO2 security keys or passkeys.

The MFA Strength Hierarchy

    MFA METHODS (weakest to strongest)
    ====================================

    SMS Codes          [====                ] Vulnerable to SIM swap
    Email Codes        [=====               ] Vulnerable if email compromised
    TOTP Apps          [============        ] Google Auth, Authy: solid
    Push Notifications [=============       ] Duo, MS Authenticator
    Hardware Keys      [=================== ] YubiKey, FIDO2
    Passkeys           [====================] Phishing-resistant by design

Passkeys: The Future of Authentication

Passkeys represent the most significant change to authentication since passwords were invented. They use public-key cryptography to eliminate passwords entirely, and they are phishing-resistant by design.

Here is how passkeys work, simplified:

    PASSKEY AUTHENTICATION
    =======================

    Registration (one time):
    +--------+                    +---------+
    | Device |  1. Create key    | Server  |
    |        |     pair           |         |
    |        |  Private key stays |         |
    |        |  on device         |         |
    |        |  2. Send public -> |  Stores |
    |        |     key            | public  |
    +--------+                    | key     |
                                  +---------+

    Login (every time):
    +--------+                    +---------+
    | Device |  1. Server sends  | Server  |
    |        | <-- challenge ---  |         |
    |        |                    |         |
    |        |  2. User confirms  |         |
    |        |  (biometric/PIN)   |         |
    |        |                    |         |
    |        |  3. Sign challenge |         |
    |        |  with private key  |         |
    |        |  --- signature --> |  Verify |
    |        |                    | with    |
    +--------+                    | public  |
                                  | key     |
                                  +---------+

Why passkeys matter so much:

No shared secrets. The server never sees the private key. If the server is breached, attackers get public keys, which are useless for impersonation.
Phishing-resistant. Passkeys are bound to the website's domain. A fake login page on a lookalike domain simply will not work, because the passkey will not activate.
No passwords to steal, reuse, or forget. The entire category of password-based attacks becomes irrelevant.
User experience is better. Tap your fingerprint or look at your phone. That is it. No typing, no remembering, no password managers.

Apple, Google and Microsoft all support passkeys across their platforms. If you are entering cybersecurity, understanding passkeys is not optional, because they are where authentication is heading.

Single Sign-On (SSO) and Federation

SSO allows users to authenticate once and access multiple applications without logging in again. Federation extends this concept across organizational boundaries.

How SSO Works

Component	Role	Examples
Identity Provider (IdP)	Authenticates users, issues tokens	Okta, Microsoft Entra ID, Google Workspace
Service Provider (SP)	The application the user wants to access	Salesforce, Slack, Jira
Protocol	The standard they use to communicate	SAML 2.0, OIDC, OAuth 2.0

OAuth 2.0 and OpenID Connect (OIDC), Simplified

OAuth and OIDC are the protocols that power modern SSO. They are related but different:

OAuth 2.0 is an authorization framework. It answers "is this app allowed to access this resource on behalf of this user?" Think of the "Sign in with Google" button: you are authorizing the app to read your Google profile.
OIDC is an authentication layer built on top of OAuth 2.0. It adds identity. It answers "who is this user?" by providing an ID token with user information.

    OIDC/OAuth 2.0 SIMPLIFIED FLOW
    ================================

    User        App (Client)      Auth Server       Resource
     |              |                 |               |
     | 1. Click     |                 |               |
     |  "Login"     |                 |               |
     | -----------> |                 |               |
     |              | 2. Redirect to  |               |
     |              |    auth server  |               |
     | <----------- | --------------> |               |
     |                                |               |
     | 3. User logs in at auth server |               |
     | -----------------------------> |               |
     |                                |               |
     | 4. Auth server redirects back  |               |
     |    with authorization code     |               |
     | <----------------------------- |               |
     | -----------> |                 |               |
     |              | 5. Exchange     |               |
     |              |    code for     |               |
     |              |    tokens       |               |
     |              | --------------> |               |
     |              | <-------------- |               |
     |              |  (access token  |               |
     |              |   + ID token)   |               |
     |              |                 |               |
     |              | 6. Use access   |               |
     |              |    token to     |               |
     |              |    call API     |               |
     |              | -----------------------------> |
     |              | <----------------------------- |
     |              |                                |
     | 7. Return    |                                |
     |    data      |                                |
     | <----------- |                                |

Note

If you want to build a career in application security or identity engineering, you need to understand OAuth 2.0 and OIDC cold. These protocols power the authentication for virtually every modern web and mobile application. Security vulnerabilities in OAuth implementations are extremely common and consistently appear in bug bounty programs.

The LoginRadius Story: A Teaching Moment

I want to share how LoginRadius came to be, not just for the story, but because it illustrates important concepts about identity at scale that you will encounter in your career.

When I started LoginRadius, the CIAM space barely existed as a category. Companies were building their own login systems, and building them badly. Password storage was done wrong. Session management was an afterthought. Social login implementations were riddled with vulnerabilities. Every company was reinventing the wheel, and most of the wheels were broken.

The insight was simple: authentication is a solved problem, but only if you actually implement the solution correctly. Most development teams do not have deep identity security expertise. They build "good enough" authentication, ship it, and move on to features that generate revenue. Then they get breached.

LoginRadius scaled to more than a billion users because it abstracted away the complexity. Developers get a secure authentication system they can integrate in hours instead of building one from scratch over months. The system handles password hashing, session management, MFA, social login, GDPR compliance, and dozens of other identity concerns correctly, so individual development teams do not have to become identity security experts.

This is a pattern you will see throughout security: the most impactful security work often involves making the secure option the easy option. If doing the right thing requires extra effort, people will not do it. If it is the default, they will.

Why Identity Is Career Gold

Let me make the career case for identity security, because it is one of the strongest specialization paths in the field.

Factor	Identity Security Advantage
Demand	Every organization needs identity infrastructure
Supply	Fewer people specialize in it; many newcomers chase pen testing or SOC roles
Salary	Indicative IAM engineer base pay runs from about $80K at entry to about $270K at principal level (see the Chapter 1 table)
Impact	Credential abuse is one of the top two ways into a breach (Verizon DBIR); you defend a heavily attacked surface
Growth	Cloud migration, zero trust, passkeys and AI agents all drive identity investment
Versatility	Identity skills apply in every industry, every company size
Career paths	IAM Engineer -> IAM Architect -> CISO is a well-worn path

The market signals are hard to miss. In February 2026, Palo Alto Networks completed its roughly $25 billion acquisition of CyberArk, the privileged access vendor. Okta, SailPoint, Ping Identity and Microsoft keep investing because identity is becoming more complex, not simpler. Multi-cloud environments, remote workforces, API-first architectures, and regulatory requirements all make identity harder.

Common Identity Vulnerabilities

To be useful in your career, here are the identity vulnerabilities you should understand:

Vulnerability	What It Is	Real-World Impact
Credential Stuffing	Using stolen credentials from one breach on other sites	Billions of credential pairs are available on dark web
Password Spraying	Trying common passwords against many accounts	Bypasses lockout policies by going slow and wide
Session Hijacking	Stealing or forging session tokens	Attacker becomes the user without knowing the password
Broken Access Control	Authorization flaws that let users access others' data	OWASP #1 vulnerability category
Insecure Direct Object Reference (IDOR)	Accessing resources by manipulating IDs in URLs/requests	User changes "account_id=123" to "account_id=124"
Token Leakage	JWTs or OAuth tokens exposed in logs, URLs, or errors	Gives attacker the keys to the API
MFA Bypass	Techniques to circumvent multi-factor authentication	Social engineering help desks, MFA fatigue attacks
Account Takeover	Full compromise of a user account through any vector	Combines multiple techniques for complete access

Hands-On: Identity Security Exercises

Exercise 1: Analyze Your Own Authentication

Pick five services you use daily. For each one, document:

What authentication method do they use?
Is MFA available? Is it enabled? What type?
What happens when you request a password reset?
What session timeout is configured?
Do they support passkeys?

Exercise 2: OAuth Flow Tracing

Go to any website that offers "Sign in with Google." Open your browser's developer tools (Network tab). Click the login button and trace every redirect, every token exchange, every parameter. Map what you see to the OIDC flow diagram above. This is how you learn protocols: by watching them in action.

Exercise 3: Identity Threat Modeling

Pick a simple web application (your blog, a side project, or a test app). Map out every authentication and authorization decision in the application. For each one, ask:

What happens if this control fails?
How would an attacker bypass this?
What would they gain?

Tip

Identity security is one of the few specializations where you can practice on production systems you already use. Every time you log into a website, you are interacting with an identity system. Developing the habit of analyzing these systems builds your skills without any special tools or lab environment.

The Path Forward

Identity is the foundation of modern security. Whether you end up specializing in identity or not, the concepts in this chapter will serve you in every security role. Understanding authentication, authorization, SSO, MFA, and the common vulnerabilities in identity systems is baseline knowledge for any security professional.

If identity excites you as a specialization, the path is clear. Learn OAuth 2.0 and OIDC deeply. Get hands-on with an identity provider (Auth0's free plan or the open-source Keycloak are good starting points), consider IDPro's CIDPRO certification, and build a project that demonstrates your skills, such as a secure authentication system with passkey support. For a free, structured route, the Start Here path on Start with Identity, the non-profit identity community I run, goes from concepts to protocols to hands-on recipes. Its glossary defines the terms in this chapter and many more.

Now let us move from theory to practice. In the next chapter, we build a home lab where you can experiment with these concepts and many others in a safe environment.