Phase 4: Security Features — Part 2 (Self-Service Registration & Password Recovery)

Same theme as the rest of this phase: because TaskFlow uses the redirect model built in Phase 2 — where the login experience lives on Okta's hosted page — everything below is configured entirely in the Okta Admin Console. No changes to your Next.js code are needed for either feature.

Self-Service Registration: Letting Users Sign Themselves Up

Right now, every TaskFlow user has to be manually created by you in the Admin Console. Self-service registration adds a "Sign up" link directly on Okta's hosted login page, letting new users create their own account.

Step 1: Create a User Profile Policy

  1. In the Admin Console, go to Security → User Profile Policies.
  2. Click Add user profile policy — creating one scoped specifically to TaskFlow keeps registration rules isolated from any other apps in your org.
  3. Give it a name, e.g. TaskFlow Registration Policy, and click Save.

Step 2: Configure Enrollment Settings

  1. Open the policy, go to its Enrollment tab.
  2. Under Profile Enrollment, click Edit.
  3. Set Self-service registration to Allowed — this is what makes a "Sign up" link appear on Okta's hosted Sign-In page.
  4. Leave Progressive Profiling as Enabled — this lets Okta ask for any missing attributes on a later sign-in rather than forcing everything up front.
  5. Set Email verification to Required before access is granted — this means a self-registered user must click a confirmation link in their email before their account becomes usable, which keeps out spam signups and typo'd addresses.
  6. Add the user to group — optionally select a group here to auto-assign every self-registered user into it (e.g., a TaskFlow-Free group). Leave as None if you don't need this yet.
  7. Click Save.

Step 3: Configure the Registration Form

Still on the policy, scroll to Profile enrollment form:

  1. By default you'll see First name, Last name, and Primary email, all Required.
  2. Click Add form input for any additional fields you want — for example Mobile phone as Optional, or any custom attribute defined back in Phase 3.

Step 4: Attach the Policy to TaskFlow

  1. On the policy, click the Apps tab.
  2. Click Add an App to This Policy.
  3. Select TaskFlow, click Apply, then Close.
  4. Confirm TaskFlow now appears under Apps using this policy.

Step 5: Assign TaskFlow to a Group

Self-service registration specifically requires the app to be assigned to a Group, not just individual people — this is an Okta requirement worth setting up correctly from the start:

  1. Go to Applications → TaskFlow → Assignments.
  2. Click Assign → Assign to Groups.
  3. Select Everyone (or a custom group your org uses), click Assign, then Save and Go Back, then Done.

Try It

Open http://localhost:3000/login, click Log in with Okta. On Okta's hosted Sign In page, you'll now see:

Don't have an account? Sign up

Click through it — you'll get a registration form based on the fields configured in Step 3, an email verification step, and then land back into TaskFlow's /dashboard as a brand-new, real Okta user — created entirely through Okta's own UI, no code of ours involved.

A Note on Username

By default, Okta uses the registrant's email address as both their username and their primary email — this matches how most modern apps behave, and is the current recommended default.


Self-Service Password Recovery

This is the "Forgot password?" flow — one of the clearest wins for offloading identity to Okta instead of building it yourself.

Step 1: Enable It on the Password Authenticator

  1. Go to Security → Authenticators, find Password, click Actions → Edit.
  2. Under Rules, edit the default rule (or add a new one).
  3. Enable Password reset under Users can perform self-service.
  4. Under Recovery authenticators, choose which methods a user can use to prove their identity before resetting — Email at minimum is a solid default.
  5. Set Access control to This rule (legacy) for straightforward behavior, or Authentication policy if you want recovery strictness to follow the same Authentication Policy rules from Phase 4, Part 1.
  6. Save.

An Important Security Detail

If you configure recovery authenticators to require something stronger than what you allow for regular sign-in — for instance, requiring Okta Verify push specifically for recovery — you can lock out a genuine user who lost the device holding Okta Verify, which is often the whole reason they needed recovery in the first place. A sensible default for TaskFlow: allow Email as a standalone recovery method, since it doesn't depend on a device the user might have already lost.

Step 2: Try It

From /login, enter the account's email or username on Okta's first screen and click Next. On the password screen that follows, you'll see Forgot password? directly below the password field. Click it, enter the account's email, and Okta sends a reset link — clicking it lets the user set a new password directly on Okta's page, then returns them through the same flow into /dashboard.


Where TaskFlow Stands

New users can self-register through a properly configured registration form with email verification, and any user can recover a forgotten password safely — all without a single new line of application code, because the entire experience is Okta's hosted page reacting to policies configured here.

No comments:

Post a Comment

Phase 4: Security Features — Part 2 (Self-Service Registration & Password Recovery)

Same theme as the rest of this phase: because TaskFlow uses the redirect model built in Phase 2 — where the login experience lives on Okta...