1 RADIUS
RADIUS (Remote Authentication Dial-In User Service) despite its dated name remains widely used for corporate Wi-Fi, VPN authentication, network access, firewalls, routers, Network Access Control, and remote-access infrastructure.
The VPN gateway acts as a RADIUS client; the RADIUS server performs or coordinates the actual authentication decision.
Access-Request, Access-Accept, Access-Reject, Access-Challenge — the challenge type enables multi-stage authentication (password accepted → challenge → enter OTP → request → accept).RADIUS and MFA
RADIUS is frequently the bridge between legacy network infrastructure and modern MFA: Employee → VPN → RADIUS → Identity/MFA platform → mobile approval → RADIUS Access-Accept → VPN established. This lets an old VPN appliance benefit from modern MFA without understanding modern protocols itself.
RADIUS in legacy environments
RADIUS has historically supported authentication methods of very different security quality — PAP, CHAP, MS-CHAP, MS-CHAPv2, and various EAP mechanisms. Never assume "RADIUS authentication" automatically means the underlying method is strong; you have to examine the complete authentication chain, not just the outer protocol name.
2 Certificates, PKI & Smart Cards
Digital certificates associate an identity with a public cryptographic key, and are used throughout HTTPS, VPN authentication, Wi-Fi authentication, smart cards, device authentication, code signing, email signing, and server/client authentication.
Asymmetric cryptography uses a key pair: a private key that must stay secret, and a public key that can be distributed freely. A certificate binds the public key to an identity, e.g. Subject vpn.company.com, Issuer Company CA.
www.example.com's certificate builds a chain up to a trusted Root CA before trusting the server — the foundation of how HTTPS trust actually works.Machine authentication and mutual TLS
Certificates aren't only for people. A managed laptop might authenticate to corporate Wi-Fi with a machine certificate via RADIUS, reducing dependence on reusable user passwords. With mutual TLS (mTLS), both server and client present certificates and authenticate each other cryptographically — widely used in APIs, financial services, microservices, B2B integrations, and Zero Trust architectures.
Smart cards
Smart cards remain important in government, defence, banking, healthcare, critical infrastructure and privileged administration. Rather than storing a reusable password, the card protects private keys directly:
User inserts smart card → enters PIN
→ card unlocks cryptographic operation
→ challenge signed with private key
→ server validates certificate/signature → authentication succeedsSomething you have (the card) plus something you know (the PIN) — genuine MFA. Don't assume smart cards are obsolete just because passkeys are newer; both are legitimate public-key-based approaches, deployed in different contexts.
3 Sessions, Tokens & Logout
Authentication doesn't normally happen on every single request. After a successful login, an application creates a session so the user isn't re-authenticating on every page.
Web apps commonly track sessions with cookies (Set-Cookie: session=ABC123...), protected with attributes like Secure, HttpOnly, and SameSite. If an attacker steals a valid session token, they may not need the password or MFA at all — the application may simply believe they're the legitimate user. This is exactly why authentication security can't stop at MFA; endpoint security, browser security, token protection, session monitoring, short lifetimes, and reauthentication for sensitive actions all matter too.
Closing a browser tab doesn't necessarily destroy a server-side session, and SSO makes logout genuinely harder because several sessions can exist at once: the application session, the identity provider session, the OAuth token, the refresh token, and the device session. Logging out of one doesn't automatically terminate the others — a subtlety that matters a lot during incident response.
If an employee's laptop is stolen, disabling the user or changing their password alone may not be enough — security teams also need to revoke active sessions, revoke refresh tokens, revoke device trust, revoke certificates, and reset credentials. Modern incident response has to consider the entire set of authentication artefacts, not just the password.
4 Authentication Logging & Troubleshooting
Authentication logs are extremely valuable to SOC teams: successful/failed logins, MFA challenges and results, password resets, new authentication methods, new device registrations, token issuance/refresh, session revocation, account lockouts, and certificate/SSO authentication events — ideally with timestamp, username, source IP, device, application, method, result, risk level, and failure reason.
🔮 Predict first
02:13 Failed password login London
02:14 Failed password login London
02:16 Successful password Unknown country
02:16 MFA approved
02:17 New device registered
02:19 Mailbox accessed
02:23 New forwarding rule createdWhat should a SOC analyst flag here, and why?
Reveal the analysis
Two failed logins from London followed immediately by a success from an unknown country is already suspicious. MFA being approved right after doesn't clear it — combined with a brand-new device registration and a new mailbox forwarding rule minutes later, this is a textbook account-takeover-and-mailbox-persistence pattern (compare Module 8, Section 22's BEC scenario). Authentication logs are frequently the first indication that an account has been compromised, and forwarding-rule creation right after a suspicious login is one of the highest-value signals a SOC analyst can act on.
Troubleshooting methodically
A user reports: "I can enter my username and password, I approve MFA, but the application says Access Denied." A weak troubleshooter immediately resets the password. A better engineer maps the flow and asks where it actually broke:
Password ✓ → MFA ✓ → Authentication ✓
→ Token generated ? → Token validated ?
→ User mapped correctly ? → Group membership ?
→ Application permissions ? → Authorisation ?Since MFA succeeded, the problem likely sits after authentication — this is probably an authorisation issue, not a credentials issue. That distinction (Module 9 hub, Section 1: AAA) is exactly what separates a systematic troubleshooter from someone guessing.
More broadly, don't assume "the password is wrong" by default — the failure could involve the user account, MFA, certificate, network, DNS, time sync, the identity provider, the service provider, RADIUS, LDAP, Kerberos, a token, application config, the browser, the device, or policy. Trace the flow (User → Browser → Application → Identity Provider → MFA → Directory) and ask at each hop whether the request arrived, succeeded, and produced what the next hop expected.
Common HTTP authentication errors
5 Authentication in the Enterprise
A handful of themes recur constantly once authentication meets a real, messy organisation.
Core principles
Account recovery — the weak link
An organisation can deploy FIDO2 hardware keys and biometrics, then undermine all of it with account recovery based on "What is your mother's maiden name?" Effective security is only as strong as the weakest recovery mechanism. Attackers specifically target help desks, password reset flows, MFA reset processes, phone-number changes, and device registration — which is why identity verification during recovery is critical, not an afterthought.
This is also where help-desk social engineering lives: "I'm the CFO, I've lost my phone, I have an urgent board meeting, please reset my MFA immediately" deliberately stacks authority, urgency and pressure. Support staff must follow identity-verification procedures regardless of claimed seniority — an administrator who resets MFA without verifying identity can bypass every other control the company has built (see also Module 8, Section 9).
Zero Trust, assurance & privileged accounts
Zero Trust authentication (Module 8, Section 13) moves away from "inside the network = trusted" toward continuously verifying user, device, authentication strength, risk, application, location, session, and resource sensitivity together — an employee on a managed device with FIDO authentication from a low-risk location gets access; an unknown device with weak authentication from a high-risk network gets blocked.
Not every authentication method deserves the same confidence: password-only < password + SMS < password + authenticator app < FIDO2 security key + PIN. Resource sensitivity should drive the requirement — a public training portal and the production payment system shouldn't share the same bar. Administrator accounts specifically deserve extra protection: separate admin identities, FIDO2/smart cards, Privileged Access Workstations, Conditional Access, short sessions, step-up authentication, just-in-time access, PAM, and detailed logging — an admin account is one of the highest-value targets in the company.
Service accounts, secrets & the cloud
Authentication isn't only a human problem. Applications and services need identities too — historically via static service accounts (svc_database, svc_backup) with passwords that rarely changed, a real risk. Modern alternatives: managed service accounts, workload/managed identities, certificates, short-lived tokens, and secrets managers. Credentials should never be hardcoded into source code, scripts, config repos, container images, or documentation.
Cloud environments make identity the new perimeter — historically companies protected a network boundary; modern cloud environments have thousands of APIs, remote workers, SaaS, multi-cloud, automation, and serverless workloads instead. Cloud authentication spans human identities, machine identities, workload identities, API authentication, federation, temporary credentials, MFA, and certificates.
Global companies & migration
Large international organisations juggle multiple Active Directory forests, acquired companies with their own identity platforms, contractors, partners, legacy applications, cloud migration, data residency, and wildly different security maturity levels. An acquisition of "Company B (AD + Okta)" and "Company C (LDAP + legacy apps)" by "Company A (AD + Entra ID)" produces exactly the tangled hybrid identity architecture Lesson 5 described — IAM professionals spend a lot of their careers rationalising exactly this.
Authentication modernisation is rarely a single cutover. A typical path: password only → password + MFA → federated SSO → risk-based authentication → FIDO2/passkeys → reduced password dependency — with legacy applications often remaining for years at the earlier stages. Engineers need to be fluent in both ends of that timeline at once.
6 Comparisons Cheat Sheet
These pairings come up constantly — in this course, in real environments, and in interviews.
Being able to explain each pairing in one or two sentences is frequently more valuable in interviews than memorising any single protocol's specification.
Interview Questions
Lab Lab 1 – Session Lifecycle
Using any test web application, log in and inspect the session cookie in your browser's dev tools. Then: log out and attempt to reopen a protected page; separately, log in again and wait for the session timeout before retrying.
🔮 Predict first
What's the difference between "identity authentication" and "application session" — and why does that distinction matter for logout in an SSO environment?
Reveal the answer
Authentication is the one-time event of proving who you are; the session is the ongoing state the application uses afterward so it doesn't have to repeat that proof on every request. In SSO, logging out of one application's session doesn't necessarily end the identity provider's session, any OAuth tokens, or other application sessions built on the same login — which is exactly why "am I actually logged out everywhere?" is a genuinely hard question during incident response.
Lab Lab 2 – Capture RADIUS Traffic
Build a small lab: a RADIUS client talking to a RADIUS server. Trigger an authentication attempt and capture the traffic in Wireshark.
🔮 Predict first, then capture
Before capturing, predict what message types you'll see for a successful login versus a failed one. Then identify Access-Request, Access-Challenge, Access-Accept, and Access-Reject in the capture, and deliberately enter an incorrect credential to compare the packet flow.
Reveal what you should see
A successful attempt ends in Access-Accept; a failed one ends in Access-Reject, typically after the same initial Access-Request. This is the same predict-then-inspect approach used for Wireshark labs back in Module 3 — seeing the actual protocol on the wire makes "RADIUS authentication" concrete instead of abstract.
Lab Lab 3 – Inspect a Website Certificate
Open any HTTPS website's certificate in your browser. Inspect Subject, Issuer, Validity, Public key, Signature, Subject Alternative Names, and the full certificate chain up to the Root CA.
🔮 Predict first
Why does your browser trust this particular website's certificate, but shows a warning for a self-signed one on another site?
Reveal the answer
Your browser ships with a built-in list of trusted Root CAs. If the chain you inspected leads back to one of those roots, it's trusted automatically. A self-signed certificate has no such chain — it's effectively vouching for itself — so the browser has no basis to trust it without you explicitly telling it to.
Lab Lab 4 – Two Scenario Walkthroughs
Scenario A — Troubleshooting. A user reports: "I can enter my username and password, I approve MFA, but the application says Access Denied."
🔮 Predict first
What's your first diagnostic step — and why is resetting the password not it?
Reveal the reasoning
Since both the password and MFA succeeded, the failure is almost certainly downstream of authentication — check token generation, token validation, user mapping, group membership, and application permissions before touching credentials at all. Resetting the password addresses a step that already worked.
Scenario B — Security. Administrators are protected with password + push MFA. An attacker steals a password via phishing and sends repeated MFA push requests until the administrator accidentally approves one.
🔮 Predict first
Name at least two stronger controls the company should adopt, and explain what specifically each one fixes about this attack.
Reveal example answers
Number matching (Lesson 2) removes blind-approval; FIDO2 security keys or passkeys remove push approval entirely, replacing it with a physical touch/biometric bound to the legitimate site; risk-based controls and Privileged Access Workstations reduce how much a stolen password alone can achieve. The underlying lesson: not all MFA provides the same security — push-only MFA is meaningfully weaker than phishing-resistant methods for exactly the population (administrators) who need the strongest controls.
Capstone – Enterprise Authentication Architecture
Design authentication for a fictional multinational: 10,000 employees, 20 countries, hybrid workforce, Active Directory, Microsoft 365, AWS, a corporate VPN, a legacy HR system, a modern customer portal, privileged administrators, and manufacturing sites.
🔮 Design this yourself before revealing
For each of the following, choose an authentication technology from across all 6 lessons and be ready to explain why: employee Windows login · Microsoft 365 · the legacy HR system · VPN access · privileged administrators · the customer portal · manufacturing devices.
Reveal one possible architecture
There's no single correct architecture here — what matters is that every choice is justified by the constraints of that specific system (legacy protocol support, user population, risk level), not picked at random.
Putting It All Together
A single real enterprise can easily contain every generation of authentication technology covered in this module simultaneously: Windows workstations on Kerberos, an old internal application on LDAP, VPN on RADIUS + MFA, Salesforce on SAML, a modern web app on OpenID Connect, a backend API on OAuth, administrators on FIDO2 security keys, a customer mobile app on passkeys, manufacturing devices on certificates, and government users on smart cards. This is not unusual — it's the normal state of a company that has grown, acquired other companies, and modernised gradually rather than all at once.
Whatever the protocol, the questions an authentication or IAM engineer is expected to answer stay the same:
Module 9 Outcome
Across all 6 lessons, you should now be able to: explain AAA and the identity lifecycle; explain how passwords are hashed and salted and identify the major password attacks; explain MFA, biometrics, and why FIDO2/passkeys are phishing-resistant; explain OAuth roles and the Authorization Code + PKCE and Client Credentials flows; distinguish access, refresh and ID tokens and validate a JWT; explain OpenID Connect and SAML federation and compare the two; explain Kerberos tickets, why environments fall back to NTLM, and how LDAP directories work; explain RADIUS, certificates/PKI and smart cards; explain session security and token revocation; troubleshoot authentication methodically instead of guessing; and design a basic enterprise authentication architecture and justify each choice.
The key lesson of this whole module: authentication is no longer simply a username and password. It's an ecosystem of identities, devices, cryptography, federation, tokens, certificates, MFA, risk engines, sessions and APIs — and an engineer who understands how those pieces interact has skills that transfer directly into IAM, cybersecurity engineering, cloud security, SOC operations, incident response, Active Directory security, application security, API security, Zero Trust architecture, and privileged access management. Module 10 builds on this directly with Identity and Access Management.