Phase 4: Security Features — Part 3 (Social Login & Passwordless)

Social Login: Signing In With Google, Microsoft, or GitHub

Okta calls this Inbound Federation — Okta sits between your app and an external identity provider, handling the handshake so your app never talks to Google (or whichever provider) directly. TaskFlow still receives the same ID token and access token through the exact same callback route built in Phase 2 — nothing changes on the code side.

Step 1: Register TaskFlow as an OAuth App With the Provider

Before Okta can offer "Sign in with Google," Google needs to know about this integration. In the Google Cloud Console, create an OAuth 2.0 Client ID (under APIs & Services → Credentials). For the Authorized redirect URI, use Okta's own callback URL — not yours — which follows the pattern https://{yourOktaDomain}/oauth2/v1/authorize/callback. You'll get a Client ID and Client Secret from Google; these go into Okta, not your .env.local.

Step 2: Add the Identity Provider in Okta

1. Go to Security → Identity Providers → Add identity provider.
2. Select Google (or Microsoft, GitHub, etc.).
3. Paste in the Client ID and Client Secret from Step 1.
4. Configure two important settings:
   • Account linking — whether a Google sign-in should link to an existing Okta user with the same email, or always create a new one.
   • Just-In-Time (JIT) provisioning — whether a brand-new Okta user profile should be created automatically the first time someone signs in via Google. Leave this on for a smooth first-time experience.

Step 3: Add a Routing Rule — Required, Not Optional

Creating the Identity Provider alone does not make it appear on the login page. Okta needs a separate rule telling it when to offer this IdP:

1. Go to Security → Identity Providers → Routing Rules.
2. Click Add Routing Rule.
3. Rule name: something descriptive, e.g. Google for TaskFlow.
4. Set the IF conditions — who this applies to. For a straightforward setup, leave conditions broad (e.g., User is accessing: Any application, User matches: Anything).
5. Under THEN — Use this identity provider, select Use specific IdP(s), and choose the IdP you just created (e.g., Google).
6. Save.

Once both the Identity Provider and the Routing Rule exist, the Sign in with Google button appears automatically on Okta's hosted Sign-In page — no widget code, no SDK changes.

Try It

Open a fresh incognito window, go to /login, click through to Okta's hosted page. You should now see a Sign in with Google button alongside the password form. Clicking it takes the user to Google's real login page, then bounces them back through Okta and into TaskFlow's /dashboard, exactly like a normal login.

Repeat Steps 1–3 for any other provider (Microsoft, GitHub) — the pattern is identical each time.

---

Passwordless Authentication

Important Correction: Magic Link Is Not a Separate Authenticator

If you go looking under Security → Authenticators → Add Authenticator, you will not find a tile called "Magic Link" — it doesn't exist as its own authenticator type. This is a genuinely easy thing to expect and not find.

Instead, Magic Link is a built-in behavior of the Email authenticator, which is already added to your org by default. Opening Email → Actions → Edit confirms this directly — Okta's own description states: "If email is selected, Okta will send an email magic link and security token (code) to the email address enrolled by the user. The user can click on the link or enter the token (code) to gain access." Both the OTP and the magic link come from the same single email, automatically, with no separate toggle to enable one or the other.

Why You Might Not Have Seen It Yet

Having the Email authenticator enabled is not the same as offering a genuinely passwordless experience. If your existing Authentication Policy only ever uses Email as one of several acceptable second factors (alongside a required password), users will never see a standalone "sign in with just email" option — they'll always be asked for the password first. To get true passwordless sign-in, you need a dedicated rule that allows Email to satisfy login on its own, with no password required at all.

Step 1: Add a Dedicated Passwordless Rule

1. Go to Security → Authentication Policies → App sign-in, and open the policy attached to TaskFlow.
2. Click Add rule.
3. Rule name: Passwordless email sign-in.
4. Leave every IF condition at its default (Any user type, Any group, Any user, No policy, Any platform, Any IP, Risk: Any, empty custom expression) — these control who the rule applies to, and broad defaults are fine to start.
5. Under THEN:
   • Access is: Allowed after successful authentication.
   • User must authenticate with: change this from the default Any 2 factor types to Any 1 factor type. This is the key change — it's what allows a single factor (Email) to be sufficient on its own, instead of requiring a password plus something else.
   • Authentication methods: change from Allow any method to Allow specific authentication methods, then check only Email and leave every other authenticator unchecked. This restricts this specific rule to Email alone.
6. Leave the remaining settings (stay-signed-in, prompt-for-authentication timing) at their defaults.
7. Click Save.

Step 2: Set the Rule's Priority Correctly

This step matters as much as creating the rule itself. Okta evaluates rules top to bottom and stops at the first match. Go back to the policy's Rules tab and confirm your new Passwordless email sign-in rule sits at Priority 1, above the existing Catch-all Rule (which still requires password + another factor). If the Catch-all Rule is evaluated first, it will catch every login before your new rule ever gets considered, and you'll never see the passwordless option.

Drag the rule using the grip icon on its row if it isn't already on top, or use whichever reordering control your console shows.

A Note on Scope

With both rules left at broad "Any request" conditions, this new rule currently applies to every login attempt — everyone gets offered the passwordless email path first. That's fine for testing, but worth knowing: if you later want only some users to get a passwordless option while others stay on password + MFA, you'd narrow the IF conditions on this rule (for example, scoping it to a specific group) rather than leaving it wide open.

Try It

1. Open a fresh incognito window, go to /login, click Log in with Okta.
2. Enter your username/email, click Next.
3. Instead of a password field, Okta now prompts for Email verification directly — a "send code" / "enter code" style screen, since Email is the only method this top-priority rule allows.
4. Check your inbox — you'll receive an email containing both a one-time code and a magic link.
5. Either click the magic link directly, or copy the code into the widget.

This completes the login and redirects straight to /dashboard — no password ever entered.

Passkeys: The Other Genuine Passwordless Option

Separately from Magic Links, Passkeys (built on the FIDO2/WebAuthn standard) let a user authenticate using their device's built-in biometrics or a security key — Face ID, Windows Hello, a fingerprint reader, a physical YubiKey — with no password and no OTP at all. This is listed as its own authenticator tile, named Passkey (FIDO2 WebAuthn) in the current console (renamed from the older "FIDO2 (WebAuthn)" label — if you see the old name anywhere, it's the same feature).

To enable it: it's likely already added (check Security → Authenticators — it showed "Already added" in your org). Set it to Required or Optional in your Authenticator Enrollment Policy, and include it as an allowed method in any Authentication Policy rule where you want to offer it. The first time an enabled user logs in, Okta's hosted page prompts them to register a passkey using their device's biometrics, and every login afterward can use that instead of a password.

---

Phase 4 Is Complete

TaskFlow now supports, all through the same login button built in Phase 2: adaptive multi-factor authentication, self-service registration with email verification, self-service password recovery, social login through Google (or any provider added the same way), and two genuinely distinct forms of passwordless authentication — Email magic links via a dedicated single-factor rule, and device-based Passkeys. All of it verified working end to end against a real org, not just documentation.