Phase 4: Security Features — Part 1 (MFA & Adaptive Policies)

Here's the genuinely good news for this entire phase: because TaskFlow uses the redirect model we built in Phase 2 — where the actual login form lives on Okta's hosted page, not inside our Next.js app — everything in this lecture requires zero code changes. MFA, adaptive sign-on, self-service registration, social login, and passwordless — all of it is configured entirely in the Okta Admin Console, and your existing /api/auth/login route automatically benefits, because Okta simply shows a different, richer login experience on its own page. This is one of the strongest arguments for the redirect model over trying to build a custom login form yourself.

Multi-Factor Authentication: The Two Separate Policies You Need to Understand

A common point of confusion: people expect one setting called "enable MFA." Okta actually splits this into two distinct policies that work together, and understanding the difference will save you a lot of head-scratching:

1. Authenticator Enrollment Policy — Controls which MFA methods (Okta calls these "authenticators") users are allowed or required to enroll in, and when they're prompted to enroll (immediately, or with a grace period of skips). This is under Security → Authenticators in the Admin Console. Note the naming: in Okta's current Identity Engine (what your Integrator Free Plan org runs), this was renamed from the older "MFA Enrollment Policy" you'll see in outdated tutorials.
2. Authentication Policy (App Sign-in Policy) — Controls when an already-enrolled user is actually challenged for MFA during login — for example, every time, once per session, or only under risky conditions. This lives under Security → Authentication Policies → App sign-in.

In short: Enrollment Policy decides what methods exist for a user to use. Authentication Policy decides when Okta actually asks for them.

Step 1: Enabling Authenticators

Go to Security → Authenticators in the Admin Console. You'll see a list of available authenticator types. Okta enables Okta Verify (its own push-notification/TOTP app) and Password by default. To add more:

• Click Add authenticator.
• Common beginner-friendly choices: Email (sends a one-time code — good default, no app install needed), Phone (SMS or voice call), and Okta Verify (push notification to a phone, most secure and lowest-friction once installed).
• For each one you add, you'll configure whether it's Required, Optional, or used only for specific policies.

For this course, enable Okta Verify and Email — enough to demonstrate a real MFA prompt without needing extra third-party accounts.

Step 2: Building the Authenticator Enrollment Policy

Still under Security → Authenticators, click the Enrollment tab. Here you define enrollment policies that determine which authenticators a given group of users must set up, and how strictly. For TaskFlow:

1. Click on the default policy (or Add a Policy for a specific group, like requiring stricter enrollment for an "Admins" group later).
2. Set Okta Verify to Required.
3. Set Email to Optional (a backup method).
4. Save.

Once saved, the next time a user without Okta Verify enrolled tries to log in, Okta's hosted page will automatically prompt them to set it up — scanning a QR code with their phone — entirely on Okta's side, before redirecting back to your redirect_uri.

Step 3: Requiring MFA at Login — the App Sign-in Policy

Enrollment alone doesn't force MFA to be checked at every login — that's the Authentication Policy's job. Go to Security → Authentication Policies → App sign-in, and find (or create) the policy attached to your TaskFlow application.

Every App Sign-in Policy starts with a single catch-all rule that applies to everyone by default. Click into it (or Add rule to create a more specific one above it) and configure:

• IF conditions — who this rule applies to (e.g., "any user," or scoped to a specific group).
• THEN — Access — set to Allowed.
• THEN — Authentication requirements — this is the key setting. Choose Password + Another factor to require MFA on every login, or explore the Possession factor options (like Okta Verify specifically) for stronger requirements.
• Re-authentication frequency — how often a returning user must re-prove MFA: every sign-in, once per session, or on a custom interval.

Save, and log out and back into TaskFlow (http://localhost:3000/login) to see it in action — Okta's hosted page will now prompt for your password, then a second factor, before redirecting back to /dashboard.

Step 4: Making It Adaptive — Contextual Rules

"Adaptive MFA" just means: instead of one blanket rule for everyone, you stack multiple rules with different conditions, and Okta evaluates them in priority order (rules are checked top to bottom; the first matching rule wins). This lets you ask for MFA only when something looks risky, and skip friction otherwise.

Inside the same App Sign-in Policy, click Add rule and explore the IF conditions available — these are the actual signals Okta can evaluate:

• User's risk score — Okta's own behavioral risk analysis (available depending on plan/features enabled).
• Device is not registered / New device — the specific behavior detector mentioned in Okta's own current release notes as something you can combine with "MFA required" in a policy.
• Network zone — e.g., require stricter MFA outside your office's known IP range, or when connecting through an anonymizing proxy.
• User's group membership — different rules for different groups (this becomes very useful once we build role-based access in Phase 5).

A realistic adaptive setup for TaskFlow: one rule at the top that says "if device is new/unrecognized, require Password + Okta Verify," and the catch-all rule below it set to "Password only" for recognized, trusted devices. Because rules are evaluated in order and the first match wins, place your stricter, more specific rules above the general catch-all.

Step 5: Verifying the Right Engine

One thing worth double-checking now, since old tutorials frequently mix this up: if you ever see menu items called "Sign On Policies" (singular, under an older-looking menu) instead of "Authentication Policies → App sign-in", that means you're looking at documentation for Okta Classic Engine, not Identity Engine — the two have genuinely different menus and concepts, and Classic Engine guidance won't match what you see in your own console. Every Integrator Free Plan org (what we set up in Phase 1) runs on Identity Engine, so always confirm you're following Identity Engine-specific docs and instructions like the ones in this lecture.

---

What TaskFlow Has Now

Without touching a single line of Next.js code, TaskFlow now enforces real, configurable, adaptive multi-factor authentication — enrollment requirements, per-app authentication rules, and contextual conditions like new-device detection — all live-tested through the same login button we built in Phase 2.