Breaking into Cybersecurity

Identity: The Foundation Most People Skip

The Number That Should Change How You Think About Security

Here is a statistic that rewired my brain when I first internalized it: 88% of breaches involve compromised credentials or identity-based attacks. Not 88% of some niche category - 88% of all breaches.

Think about what that means. If you are building a career in cybersecurity and you do not deeply understand identity - how authentication works, why authorization fails, what makes credential systems vulnerable - you are ignoring the attack vector behind nearly 9 out of 10 breaches.

I did not stumble into identity security by accident. I founded LoginRadius, a customer identity and access management (CIAM) platform that now serves over a billion user identities. 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 item on 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 | Azure AD | 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, Azure AD, Ping Identity LoginRadius, Auth0, AWS 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:

  1. 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.

  2. 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.

  3. 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.

  4. 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 are a game-changer:

  1. No shared secrets. The server never sees the private key. If the server is breached, attackers get public keys - which are useless for impersonation.

  2. Phishing-resistant. Passkeys are bound to the website's domain. A fake login page on a lookalike domain simply will not work - the passkey will not activate.

  3. No passwords to steal, reuse, or forget. The entire category of password-based attacks becomes irrelevant.

  4. User experience is better. Tap your fingerprint or look at your phone. That is it. No typing, no remembering, no password managers.

Major platforms (Apple, Google, Microsoft) now support passkeys across their ecosystems. Enterprise adoption is accelerating. If you are entering cybersecurity, understanding passkeys is not optional - they are the future of authentication.

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, Azure AD, 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 reached over a billion user identities because we 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 Few people specialize in it - most chase pen testing or SOC roles
Salary IAM engineers command $120K-$270K (see Chapter 1 salary table)
Impact 88% of breaches involve identity - you are defending the most attacked surface
Growth Cloud migration, zero trust, passkeys - 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 identity security market is projected to exceed $35 billion by 2028. Companies like Okta, CyberArk, SailPoint, Ping Identity, and yes, LoginRadius, are all growing 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 (start with a free tier of Okta or Auth0), study for the Certified Identity Professional certification, and build a project that demonstrates your skills - maybe a secure authentication system with passkey support.

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.