Secure Authentication Implementation: DevSecOps Champion

Table of Contents

1. Module 1: Implementing Secure Authentication
   • Authentication vs. Authorization
   • Core Authentication Flows
   • Authentication Factors
   • Compliance and Standards Drivers
   • Authenticating with OpenID Connect and OAuth2
   • Single Sign-On
   • Credential Stuffing Attacks
   • Demo: Exploiting a Weak Password-Recovery Flow in OWASP Juice Shop
   • Advancing Your Authentication Security Skills
2. Summary

Module 1: Implementing Secure Authentication

Almost any website, API, and even desktop software requires authentication. If authentication isn’t implemented securely, it can grant attackers full access to other people’s accounts. This module examines authentication as a core discipline for a developer security champion: what authentication actually means, the flows that make it up, the factors used to prove identity, how modern protocols like OpenID Connect and OAuth2 fit together, and how attackers exploit weak authentication implementations through techniques such as credential stuffing and weak account-recovery flows.

Authentication vs. Authorization

It is worth being very clear on what is meant by authentication. Authentication requires you to prove who you are. Depending on what you’re accessing, you may need varying amounts of proof:

• For many websites, a username and password are enough.
• A banking website might require a username, a password, and a one-time PIN code.
• Additional checks may be triggered if you haven’t logged in from that particular device before.

When you sign up for a service, you need to prove who you are, and then, every time you use that service afterward, you need to prove it again — confirming that you are the same person who originally signed up.

It’s important to understand the difference between authentication and authorization:

• Authentication usually comes first: proving who you are.
• Authorization comes next: determining which resources you are allowed to access.

There is a clear link between the two, but they are very different concerns, and conflating them in an implementation is a common source of security defects.

flowchart LR
    A[User attempts to access a resource] --> B{Authentication}
    B -->|Identity proven| C{Authorization}
    B -->|Identity not proven| D[Access denied - 401 Unauthorized]
    C -->|Permission granted| E[Access allowed]
    C -->|Permission denied| F[Access denied - 403 Forbidden]

Core Authentication Flows

There are several distinct flows associated with authentication, and each one needs to independently confirm that the user is who they say they are before it is allowed to continue.

• User creation. This might be self-signup or user creation by an administrative user. Either way, there needs to be proof that the user is genuine — often a check that they own the email address they signed up with.
• Password policy and storage. A password policy and secure storage of passwords are critical. A password should be strong and should be a secret known only to the user. System administrators should never be able to see users’ passwords in plaintext or recoverable form.
• Multi-factor authentication (MFA) management. Within credential storage comes MFA. Users need to be able to add, edit, and use MFA details for their account.
• Forgotten password. A user needs to be able to prove who they are without having their password. This flow is a very common target for attackers, since it is effectively an alternate authentication path that is sometimes weaker than the primary login.
• Change password. Changing a password is critical functionality and must involve verification of the user’s current password (or another strong factor) to prevent account takeover via a hijacked session.
• Account lockout. Too many unsuccessful login attempts should lock an account, but the rules about when and why this happens need to be carefully thought through, balancing security against denial-of-service risk (an attacker deliberately locking out a legitimate user).
• Step-up authentication. If a logged-in user wants to perform an important or sensitive action, they can be asked to re-confirm their identity with MFA or by re-entering their password, even though they already have an active session.

flowchart TD
    subgraph Lifecycle["Authentication Flow Lifecycle"]
        UC[User Creation / Signup] --> EV[Email / Identity Verification]
        EV --> PW[Password Policy Enforcement + Secure Storage]
        PW --> MFA[MFA Enrollment]
        MFA --> LOGIN[Standard Login]
        LOGIN --> LOCK{Too Many Failed Attempts?}
        LOCK -->|Yes| LOCKOUT[Account Lockout]
        LOCK -->|No| SESSION[Authenticated Session]
        SESSION --> STEPUP{Sensitive Action Requested?}
        STEPUP -->|Yes| REVERIFY[Step-up Auth: MFA / Re-enter Password]
        STEPUP -->|No| CONTINUE[Continue Session]
        LOGIN -.->|Forgot Password| FORGOT[Forgotten Password Flow]
        FORGOT --> RESET[Password Reset]
        RESET --> LOGIN
    end

Authentication Factors

So how do you actually prove that someone is who they say they are? There are several recognized factors, and the more of them that are combined, the stronger the proof of identity becomes.

• Something you know — commonly a password.
• Something you have — often a mobile/cell phone with a one-time PIN generator, or a device that accepts push notifications from a service.
• Something you are — biometric proof such as a face or fingerprint.
• Somewhere you are — an increasingly common fourth factor, derived from the IP address being used, which is linked to a geographic location. Authenticating from your usual location helps to prove that it’s really you.

mindmap
  root((Authentication Factors))
    Something you know
      Password
      PIN
      Security question
    Something you have
      Mobile phone OTP app
      Push notification
      Hardware token FIDO U2F/FIDO2
      SMS code
    Something you are
      Fingerprint
      Face recognition
    Somewhere you are
      IP-derived location
      Device/network reputation

Not all factors are equally strong:

• Sending a one-time PIN via SMS to someone’s cell phone is not considered very secure, because cell phone numbers can often be cloned (SIM-swap attacks).
• Using a hardware token is considered very secure. This includes small physical keys that connect via USB or NFC. An attacker would need physical possession of the key to authenticate as the victim, which makes remote, internet-based attacks very difficult.
• The FIDO U2F protocol is an open standard that supports hardware tokens as a second factor. FIDO2 extends this to make hardware tokens a fully secure primary or secondary authentication option, usable in many scenarios — from logging into a computer to authenticating to a web application.

sequenceDiagram
    participant U as User
    participant B as Browser/App
    participant RP as Relying Party (Website)
    participant KEY as FIDO2 Hardware Authenticator

    U->>B: Initiate login
    B->>RP: Request authentication challenge
    RP-->>B: Cryptographic challenge (public key credential request)
    B->>KEY: Forward challenge
    U->>KEY: Physical presence / touch / biometric unlock
    KEY-->>B: Signed assertion (private key never leaves device)
    B->>RP: Submit signed assertion
    RP->>RP: Verify signature using stored public key
    RP-->>U: Authentication successful

Compliance and Standards Drivers

Getting authentication right protects users, data, and the organization — but there are also regulatory standards and compliance obligations to consider. Frameworks such as FIPS, PCI DSS, and HIPAA all address authentication and are often very specific about requirements such as using strong one-way encryption (hashing) when storing passwords. Compliance breaches related to weak authentication can be very costly for an organization, both financially and reputationally.

Authenticating with OpenID Connect and OAuth2

OpenID Connect (OIDC) is an important part of modern authentication. Authenticating with OpenID Connect pushes the user to log in on an authorization server, also known as an identity provider (IdP) — typically a third party. This means the application itself isn’t concerned with storing passwords, managing MFA, or handling any of those other complexities directly.

When a user successfully authenticates, they are passed back to the application along with an ID token, which acts as proof that the login occurred. This ID token is a JSON Web Token (JWT), and it is cryptographically signed by the identity provider to prove that the provider created it. Applications consuming the ID token can retrieve the provider’s public key, which lets them verify that the signature is valid and that the token really was issued by that provider.

// Example structure of a JWT ID token (header.payload.signature)
{
  "header": {
    "alg": "RS256",
    "typ": "JWT",
    "kid": "identity-provider-key-id"
  },
  "payload": {
    "iss": "https://identity-provider.example.com",
    "sub": "user-unique-id-12345",
    "aud": "client-application-id",
    "exp": 1735689600,
    "iat": 1735686000,
    "email": "user@example.com",
    "email_verified": true
  },
  "signature": "base64url(RSASHA256(base64url(header) + '.' + base64url(payload), privateKey))"
}

Lots of applications can use a single identity provider, but the user only needs a single set of credentials. This keeps things simple for users while also removing the complexity and security burden from individual applications.

OpenID Connect is an extension of OAuth2:

• OpenID Connect handles authentication — confirming who you are.
• OAuth2 handles authorization — granting access to resources. In particular, OAuth2 is about delegated authorization, which commonly comes into play when one application needs access to the functionality or data of another application on a user’s behalf.

While authorization is outside the scope of this module, it is useful to be aware of it, since it commonly sits side by side with authentication in real-world systems.

sequenceDiagram
    participant U as User
    participant App as Application (Relying Party)
    participant IdP as Identity Provider / Authorization Server

    U->>App: Request to log in
    App->>IdP: Redirect to authorization endpoint
    U->>IdP: Enter credentials (+ MFA if required)
    IdP-->>App: Redirect back with authorization code
    App->>IdP: Exchange authorization code for tokens
    IdP-->>App: ID Token (JWT, proves authentication) + Access Token (OAuth2, grants authorization)
    App->>IdP: Retrieve public key / JWKS
    App->>App: Verify ID Token signature
    App-->>U: User is logged in

Single Sign-On

Single Sign-On (SSO) is all about logging into multiple applications using a single set of credentials. This is where a protocol like OpenID Connect becomes especially important. The identity provider might be something like a Microsoft or Google authentication service, which is expected to be highly secure.

Signing in once with a work email address could give an employee access to all the applications they need to do their job. This drastically reduces the number of credentials a person needs to manage, and — importantly — when they leave their job and lose access to their work email address/identity, they can no longer access business information across all of the applications tied to that identity. There are clear security and usability benefits to this model.

sequenceDiagram
    participant U as User
    participant IdP as Central Identity Provider (e.g. Microsoft/Google)
    participant App1 as Application A
    participant App2 as Application B
    participant App3 as Application C

    U->>IdP: Log in once with work credentials
    IdP-->>U: Session established with IdP
    U->>App1: Access Application A
    App1->>IdP: Verify identity via OIDC
    IdP-->>App1: ID Token confirms identity
    U->>App2: Access Application B
    App2->>IdP: Verify identity via OIDC
    IdP-->>App2: ID Token confirms identity
    U->>App3: Access Application C
    App3->>IdP: Verify identity via OIDC
    IdP-->>App3: ID Token confirms identity
    Note over U,App3: Single set of credentials grants access to all applications

Credential Stuffing Attacks

Credential stuffing is the term used for a popular method of attacking authentication systems, and it typically starts with a different application entirely.

The general attack pattern is:

1. Attackers target a website to gain access to its user database, often through an unrelated vulnerability.
2. If a vulnerability lets them in, they look for usernames and passwords. Passwords that are easily decrypted or stored in plaintext are especially valuable to attackers.
3. A list of valid credentials means attackers can try to reuse them on other websites — including yours. Users have a well-documented habit of reusing the same login details across many websites, so this type of attack always has some degree of success.
4. Against the target software, attackers automate the login process, working through the stolen username/password pairs. Crucially, they typically try each username with only one password (the one known to be valid from the breach), which can make the attack harder to detect than a traditional brute-force attack against a single account.
5. More advanced attackers distribute the attack across multiple IP addresses — for example, by using compromised IoT devices (a botnet) or cloud services where new IP addresses can be provisioned rapidly. This makes the attack even harder to detect as a coordinated campaign.

flowchart TD
    A[Attacker breaches Website X] --> B[Extracts username/password database]
    B --> C{Passwords stored securely?}
    C -->|No - plaintext/weak hash| D[Attacker easily recovers valid credentials]
    C -->|Yes - strong hash| E[Credentials are much harder to recover]
    D --> F[Attacker builds credential list]
    F --> G[Automated login attempts against Website Y - your app]
    G --> H{Users reused passwords across sites?}
    H -->|Yes| I[Successful account takeover on Website Y]
    H -->|No| J[Login attempt fails]
    G --> K[Distributed across many IPs via botnet/cloud]
    K --> L[Harder to detect as a single coordinated attack]

Defenses against credential stuffing:

• Store passwords securely. Ensure your own application never becomes a source of leaked credentials that get reused elsewhere. OWASP publishes a Password Storage Cheat Sheet with guidance on modern, approved hashing algorithms.
• Multi-factor authentication (MFA). This is the strongest defense here — if attackers know a valid username and password but don’t have access to the user’s second factor, they cannot complete the login. Unfortunately, not all users are willing to adopt MFA.
• CAPTCHA. Requiring proof that a login attempt is coming from a human (not an automated script) is a good complementary defense.
• Monitoring. A sudden spike in login attempts can signal an attack in progress. Identifying commonality among malicious requests (shared IP ranges, user-agent strings, timing patterns) can allow the requests to be blocked.

flowchart LR
    subgraph Defenses["Credential Stuffing Defenses"]
        D1[Secure password storage<br/>strong one-way hashing]
        D2[Multi-factor authentication]
        D3[CAPTCHA / bot detection]
        D4[Monitoring & anomaly detection]
    end
    D1 --> R[Reduced risk of account takeover]
    D2 --> R
    D3 --> R
    D4 --> R

For reference, OWASP’s Password Storage Cheat Sheet recommends modern, purpose-built password hashing algorithms rather than general-purpose hash functions such as plain SHA-256 or MD5:

Demo: Exploiting a Weak Password-Recovery Flow in OWASP Juice Shop

Credential stuffing is an effective attack, but exploiting other functionality in an authentication flow can mean an attacker doesn’t need a user’s password at all. This walkthrough uses OWASP Juice Shop — a deliberately vulnerable web application that can be downloaded and run for training purposes — together with an intercepting proxy (Burp Suite) to demonstrate an account-takeover attack that bypasses the password entirely.

Step-by-step walkthrough:

1. Reconnaissance. Browsing the product listings on Juice Shop, reviews are visible that include people’s email addresses. This is part of users’ login information, so publicly exposing it is already a weakness. A target username (email address) is copied from a review.

2. Navigate to account recovery. Go to the login screen, then select Forgotten password.

3. Intercept the request. With Burp Suite acting as an intercepting proxy between the browser and the application, submitting the username triggers a request that can be observed and manipulated.

   POST /rest/user/security-question HTTP/1.1
   Host: juice-shop.local
   Content-Type: application/json
   
   { "email": "victim@example.com" }
   

   The response reveals the security question configured for that account, which is then displayed on the interface — for example, asking for the user’s eldest sibling’s middle name.

   {
     "question": {
       "id": 4,
       "question": "What is your eldest sibling's middle name?"
     }
   }
   

4. Assess the security question. A question like this is something an attacker could research via social media, or simply attempt to guess — it is not a strong proof of identity.

5. Submit an initial guess. A guess is submitted, along with a new password value, to observe the response behavior.

   POST /rest/user/reset-password HTTP/1.1
   Host: juice-shop.local
   Content-Type: application/json
   
   {
     "email": "victim@example.com",
     "answer": "James",
     "new": "password",
     "repeat": "password"
   }
   

   The response indicates rate limiting is applied — for example, suggesting a maximum of 100 requests are permitted, with 99 attempts remaining. This shows that some defense exists, but it is not sufficient on its own against a well-chosen, small guess list.

6. Send the request to Intruder. The captured request is sent to Burp Suite’s Intruder tool, which automates sending many variations of the same request.

7. Configure the attack. In Intruder, the guessed answer field ("answer": "§James§") is marked as an insertion point, so that each item from a wordlist is substituted into that field automatically.

8. Build a payload list. A quick web search provides a list of the top 100 most common first names for men (since the security question asks for a sibling’s middle name and the target was inferred to be researched via typical, common naming). This list is pasted into Intruder’s Payloads configuration.

   James
   Michael
   Robert
   John
   David
   ...
   (top 100 common names)
   

9. Run the attack and observe results. The attack executes a request for each name in the list. Watching the responses, the remaining rate-limit counter can be seen decrementing with each attempt. Eventually, one request returns an HTTP 200 status — a success — indicating the correct middle name was guessed and the account password has been changed.

   Request #47  answer=Christopher   -> HTTP 401 Unauthorized
   Request #48  answer=Daniel        -> HTTP 401 Unauthorized
   Request #49  answer=James         -> HTTP 200 OK   <-- success, password reset
   

10. Confirm account takeover. Returning to the login screen and submitting the new password confirms that the account has been fully compromised — the attacker is now logged in as the victim, having never known the original password.

sequenceDiagram
    participant A as Attacker
    participant P as Burp Suite (Proxy/Intruder)
    participant App as Juice Shop Application

    A->>App: Browse product reviews, harvest victim email address
    A->>P: Submit "Forgotten Password" for victim email
    P->>App: POST /rest/user/security-question
    App-->>P: Security question returned (e.g. eldest sibling's middle name)
    A->>P: Send request to Intruder, mark answer field as insertion point
    A->>P: Load payload list (top 100 common names)
    loop For each candidate name
        P->>App: POST /rest/user/reset-password (guess + new password)
        App-->>P: 401 Unauthorized (rate limit counter decrements)
    end
    P->>App: POST /rest/user/reset-password (correct guess)
    App-->>P: 200 OK - password reset successful
    A->>App: Log in with new password
    App-->>A: Authenticated as victim - account fully compromised

What Juice Shop could have done better:

• Security questions like this are generally considered a weak authentication factor and should be avoided or, at minimum, never used as the sole proof of identity for account recovery.
• A better solution is typically to send an email containing a time-limited link to reset the password. The proof of identity here is that the user should be the only person capable of accessing that email account.
• If MFA is configured on the account, it is reasonable to require it as part of the recovery flow as well, since the user should still have access to that second factor when recovering their account.
• Rate limiting alone is insufficient defense against a well-curated, short guess list (such as the top 100 common names) — the underlying weakness is the low entropy of the security question itself, not just the request volume.

Advancing Your Authentication Security Skills

As a security champion, everything learned here needs to be worked into everyday software development practices:

• Automated tests should exist to prove that authentication works securely and does not suffer from the most common vulnerabilities (weak password storage, missing rate limiting, weak recovery flows, missing MFA enforcement, and so on).
• Understanding how authentication is assembled — the flows and algorithms that need to fit together correctly to be secure — is valuable even for developers who never implement authentication from scratch, because it enables better review and threat modeling of systems that use these components.
• OpenID Connect and OAuth2 usage patterns vary depending on what is being protected. Securing a microservice-based API is very different from securing a single web page application, and the right pattern (authorization code flow, client credentials, PKCE, and so on) depends on that context.
• OAuth2 and OpenID Connect are not the only standards in this space. SAML performs a similar function and uses XML for information exchange, and is still common in enterprise/legacy SSO scenarios.
• Authentication is complicated to implement correctly. It is often wise to use existing, well-vetted implementations, frameworks, and software development kits rather than building it from scratch — even for something like OpenID Connect client integration.
• If a custom authentication implementation is genuinely required, expert guidance should be sought. Useful reference material includes:
  • The OWASP Top 10, which lists identification and authentication failures among the most critical web application security risks.
  • The OWASP API Security Top 10, which covers authentication weaknesses specific to APIs.
  • OWASP Cheat Sheets, including guidance on secure password storage and authentication implementation.
  • The OWASP Application Security Verification Standard (ASVS), which has a dedicated section defining what authentication implementations should do to be considered secure.

flowchart TD
    A[Security Champion Growth Path] --> B[Write automated tests for authentication security]
    A --> C[Understand authentication flows/algorithms deeply]
    A --> D[Match protocol choice to context: API vs SPA vs enterprise SSO]
    D --> D1[OpenID Connect / OAuth2]
    D --> D2[SAML for enterprise/legacy SSO]
    A --> E[Prefer vetted frameworks/SDKs over custom implementations]
    A --> F[Consult authoritative references when custom auth is unavoidable]
    F --> F1[OWASP Top 10]
    F --> F2[OWASP API Security Top 10]
    F --> F3[OWASP Cheat Sheets]
    F --> F4[OWASP ASVS - Authentication section]

Summary

Secure authentication is foundational to protecting users, data, and organizations, and it spans a broad set of concerns:

• Authentication proves identity; authorization governs access. Keeping these concerns distinct in design and implementation avoids subtle security defects.
• Authentication is made up of multiple flows — user creation, password policy and storage, MFA management, forgotten password, change password, account lockout, and step-up authentication — each of which must independently and robustly confirm the user’s identity.
• Multiple factors strengthen proof of identity: something you know, something you have, something you are, and somewhere you are. Not all factors are equally strong; hardware tokens (FIDO U2F/FIDO2) offer the strongest practical protection, while SMS-based codes are comparatively weak.
• Compliance frameworks (FIPS, PCI DSS, HIPAA, and others) impose specific, often non-negotiable requirements on authentication and credential storage.
• OpenID Connect and OAuth2 let applications delegate authentication to a trusted identity provider, simplifying implementation while enabling patterns like Single Sign-On. OIDC handles authentication via a signed JWT ID token; OAuth2 handles delegated authorization via access tokens. SAML remains a relevant alternative, particularly in enterprise contexts.
• Credential stuffing exploits password reuse across services following unrelated data breaches, and is best defended against with strong password hashing, MFA, CAPTCHA, and monitoring.
• Weak account-recovery flows (such as low-entropy security questions) can allow full account takeover without ever knowing the original password, as demonstrated against OWASP Juice Shop — rate limiting alone is not a sufficient defense against a well-curated guess list.
• Prefer proven frameworks and SDKs over custom authentication implementations, and lean on authoritative references (OWASP Top 10, OWASP API Security Top 10, OWASP Cheat Sheets, OWASP ASVS) whenever a custom solution is unavoidable.

Secure Authentication Checklist

• Clearly separate authentication (identity) logic from authorization (access control) logic.
• Store passwords using a modern, memory-hard hashing algorithm (Argon2id, bcrypt, or scrypt), never plaintext or fast general-purpose hashes.
• Enforce a strong password policy without imposing counterproductive rules that encourage weak, predictable passwords.
• Offer and encourage MFA using strong factors (authenticator apps or hardware tokens); avoid relying solely on SMS-based codes.
• Ensure the forgotten-password flow is at least as strong as the primary login — avoid low-entropy security questions in favor of email-based reset links and/or MFA verification.
• Require the current password (or an equivalent strong factor) before allowing a password change.
• Implement account lockout and rate limiting on authentication endpoints, tuned to avoid enabling denial-of-service abuse of the lockout mechanism itself.
• Apply step-up authentication for sensitive actions performed within an already-authenticated session.
• Use OpenID Connect (with signed, verified ID tokens) or SAML to delegate authentication to a trusted identity provider where appropriate, rather than building custom authentication from scratch.
• Monitor authentication endpoints for anomalous patterns (spikes in failed logins, distributed IP sources) that may indicate credential stuffing or brute-force attacks.
• Add automated security tests covering authentication flows, including negative test cases for common vulnerabilities.
• Reference OWASP Top 10, OWASP API Security Top 10, OWASP Cheat Sheets, and OWASP ASVS when designing or reviewing authentication implementations.

Search Terms

secure · authentication · devsecops · champion · cybersecurity · fundamentals · networking · systems · security