36% of the exam — the single largest domain.
2 sub-topics · this deck covers sub-topic 1 of 2
↑ Module 4 OverviewNot every system in a company speaks SAML or OIDC. Some older infrastructure — VPN concentrators, load balancers — only understands RADIUS. This sub-topic is about how Okta bridges that gap.
The Okta RADIUS Server agent lets RADIUS-speaking infrastructure authenticate against Okta. This is commonly used to front VPN devices (like Cisco ASA) and load balancers (like F5), though the same principles extend to similar systems.
Configuring and running this agent well touches several distinct concerns, each documented as its own topic:
Session persistence and scaling considerations here echo the same reliability theme as Module 1's agent architecture content — a RADIUS agent that can't keep up with authentication volume creates the exact same kind of bottleneck an under-provisioned AD agent does.
The next sub-topic goes deeper on the high-availability side of that principle, applied specifically to RADIUS (and other advanced agents like MFA and OPP).
Watch for scenario questions built around this trap:
→ "A VPN concentrator or load balancer needs to authenticate against Okta, and it only speaks RADIUS." = deploy the Okta RADIUS Server agent.
Sources: help.okta.com — radius-best-pract.htm
Next: Sub 2 →