Step 1: Actually Verifying the ID Token
Right now our callback route stores the ID token without checking anything about it — we're just trusting that whatever arrived is genuine. That's not acceptable even for a course project. Verifying a token means checking three separate things: that its cryptographic signature is genuine (nobody tampered with it), that it hasn't expired, and that it was issued by the Okta authorization server we expect, for our specific application.
We use jose for this because of a very specific Next.js constraint: Middleware runs on the Edge Runtime, a lightweight, browser-like environment — not full Node.js. That means Node's built-in crypto module (which older JWT libraries like jsonwebtoken depend on) isn't available there. jose is built on Web Crypto APIs instead, so the exact same verification code works in Middleware, Route Handlers, and Server Components alike.
Create src/lib/verifyToken.ts:
import { jwtVerify, createRemoteJWKSet } from "jose";
const JWKS = createRemoteJWKSet( new URL(`${process.env.OKTA_ORG_URL}/oauth2/default/v1/keys`) );
export interface OktaIdTokenClaims { sub: string; email: string; name: string; [key: string]: unknown; }
export async function verifyIdToken(idToken: string): Promise<OktaIdTokenClaims> { const { payload } = await jwtVerify(idToken, JWKS, { issuer: `${process.env.OKTA_ORG_URL}/oauth2/default`, audience: process.env.OKTA_CLIENT_ID, });
return payload as OktaIdTokenClaims; }
Here's what each check does, concretely: createRemoteJWKSet fetches Okta's public signing keys from its /keys endpoint (and caches them), which jwtVerify uses to confirm the token's signature is genuine and untampered. The issuer check confirms the token was actually issued by our authorization server, not some other Okta org. The audience check confirms the token was issued for our specific application — without this check, a valid token issued to a completely different app on the same Okta org would incorrectly pass verification. jwtVerify also automatically rejects expired tokens by checking the exp claim — you don't need to check that yourself.
Now update the callback route from the last post — in src/app/api/auth/callback/route.ts, add the verification step right after you receive tokens:
import { verifyIdToken } from "@/lib/verifyToken";
// ... inside the same function, after: const tokens = await tokenResponse.json();
try { await verifyIdToken(tokens.id_token); } catch (err) { console.error("ID token verification failed:", err); return NextResponse.redirect(new URL("/login?error=invalid_token", request.url)); }
If this check ever fails in practice, it means something is seriously wrong (a misconfigured issuer, a tampered token, or a token meant for a different app) — never skip it, and never store tokens before this check passes.
Step 2: Logout
Logging a user out actually has two layers, and it's important to understand both:
- Your app's session — deleting the cookies we set, so your app itself no longer considers the user logged in.
- Okta's own session — the browser also holds a session cookie with Okta itself (that's what let you skip re-entering your password if you logged into a second app using the same Okta org). If you only clear your app's cookies, clicking "Log in with Okta" again would silently re-authenticate the user without even showing a login form, because Okta still remembers them.
A proper logout needs to end both. Create src/app/api/auth/logout/route.ts:
import { NextRequest, NextResponse } from "next/server";
export async function GET(request: NextRequest) { const idToken = request.cookies.get("id_token")?.value;
const logoutUrl = new URL(`${process.env.OKTA_ORG_URL}/oauth2/default/v1/logout`); logoutUrl.searchParams.set("post_logout_redirect_uri", "http://localhost:3000"); if (idToken) { // Okta requires the original id_token as a "hint" — proof this logout // request is tied to a real session it issued. logoutUrl.searchParams.set("id_token_hint", idToken); }
const response = NextResponse.redirect(logoutUrl.toString()); response.cookies.delete("id_token"); response.cookies.delete("access_token");
return response; }
We clear our own cookies first, then redirect the browser to Okta's /logout endpoint, which ends the Okta-side session too and sends the user back to post_logout_redirect_uri — which must exactly match one of the Sign-out redirect URIs you configured back in Phase 1, Step 2 (http://localhost:3000).
Add a logout link to the dashboard page from last time:
<a href="/api/auth/logout" className="text-red-600 hover:underline"> Log out </a>
Step 3: Protecting Routes with Middleware
Right now, /dashboard is visible to anyone, logged in or not — visiting the URL directly just shows the page, no check happens. Middleware fixes this by intercepting every matching request before it reaches your page.
Create src/middleware.ts at the root of src/:
import { NextRequest, NextResponse } from "next/server"; import { verifyIdToken } from "@/lib/verifyToken";
export async function middleware(request: NextRequest) { const idToken = request.cookies.get("id_token")?.value;
if (!idToken) { return NextResponse.redirect(new URL("/login", request.url)); }
try { await verifyIdToken(idToken); return NextResponse.next(); } catch { // Token exists but is invalid or expired — treat as logged out. const response = NextResponse.redirect(new URL("/login", request.url)); response.cookies.delete("id_token"); response.cookies.delete("access_token"); return response; } }
export const config = { matcher: ["/dashboard/:path*"], };
The matcher config is important — it tells Next.js exactly which routes this Middleware should run on. We're scoping it to /dashboard and everything under it, so /login and our /api/auth/* routes are left untouched (protecting the login page itself would create an unbreakable redirect loop). As you add more protected pages later in the course (settings, admin panels), you'll extend this matcher array.
Try it now: log out, then try visiting http://localhost:3000/dashboard directly in the address bar. You should be bounced straight to /login — the page never even renders.
Step 4: Reading the Logged-In User in a Server Component
Middleware confirms that someone is logged in, but your dashboard page still doesn't know who. Let's read the verified identity directly inside the Server Component.
Update src/app/dashboard/page.tsx:
import { cookies } from "next/headers"; import { verifyIdToken } from "@/lib/verifyToken"; import { redirect } from "next/navigation";
export default async function DashboardPage() { const cookieStore = await cookies(); const idToken = cookieStore.get("id_token")?.value;
if (!idToken) { redirect("/login"); }
const claims = await verifyIdToken(idToken);
return ( <div className="p-8"> <h1 className="text-2xl font-semibold text-slate-800"> Welcome, {claims.name} </h1> <p className="text-slate-500 mt-2">Logged in as {claims.email}</p> <a href="/api/auth/logout" className="text-red-600 hover:underline mt-4 inline-block"> Log out </a> </div> ); }
Because this is a Server Component (the default for any file in app/ that doesn't say "use client"), this code runs entirely on the server, before any HTML reaches the browser. The id_token cookie is httpOnly, so it was never accessible to client-side JavaScript anyway — this is the correct, secure way to read it. Note we're verifying the token again here, separately from Middleware — that's intentional defense-in-depth, not redundant: Middleware protects the route from being reached at all, while this check ensures the page itself never renders content based on an unverified claim, even if it were somehow reached another way (e.g., a Server Action called directly).
What's Working Now
TaskFlow now has a complete, real authentication loop: a login button that redirects to Okta, a callback that exchanges the code for tokens and cryptographically verifies them, cookies storing the session securely, Middleware blocking unauthenticated access to /dashboard, proper two-layer logout, and a dashboard that displays the real logged-in user's name and email.
This closes out Phase 2.
In Phase 3, we'll cover what the Access Token and Refresh Token are actually for, silent token renewal so users aren't logged out every hour, and fetching/updating the user's full Okta profile.