# Nuxt 3 & Vue 3 Authentication with Logto — secure OIDC/OAuth implementation

Short: pragmatic, secure, and tested patterns to add authentication to Nuxt 3 and Vue 3 apps using Logto (or your OIDC provider). Covers middleware, SSR vs SPA, token storage, redirects, refresh, and TypeScript tips.
  

Nuxt 3 & Vue 3 Authentication with Logto — secure OIDC/OAuth implementation

A compact, practical guide for web developers: how to wire authentication into Nuxt 3 & Vue 3 (SPA/SSR), using Logto or any OpenID Connect provider. Expect concrete patterns, security notes, and small code pointers — no fluff.

Why this matters (intent & what you’ll get)

Most SERP results for queries like nuxt 3 authentication, vue 3 authentication, or logto nuxt are a mix of informational docs, practical tutorials, and SDK references. Your typical user intent is mixed: developers want actionable how-tos (implementation), reference (API/SDK), and security best practices.

This article gives a single, coherent approach: implement an OIDC (OpenID Connect) – compliant flow in Nuxt 3 / Vue 3, integrate Logto as an example provider, and secure tokens correctly for both SSR and SPA use-cases.

You’ll get: middleware to guard routes, cookie/session recommendations, token refresh strategy, TypeScript-friendly patterns, and links to authoritative docs.

Core authentication approach — recommended architecture

Use OpenID Connect Authorization Code Flow with PKCE as your primary flow. It is supported by Logto and all modern providers, works for both public clients (SPA) and confidential clients (server). For Nuxt 3 SSR, prefer server-side code to handle token exchange and set an HttpOnly session cookie.

High-level flow: user clicks “Login” → redirect to Logto (or OIDC) auth endpoint with PKCE → provider authenticates → callback hits your app → server exchanges code for tokens → set secure HttpOnly cookie (session) and redirect to app. When using client-side only, use PKCE and rely on access tokens for API calls, but store tokens safely (see below).

Advantages: Authorization Code + PKCE minimizes risk of token leakage, allows refresh token usage, and lets your server rotate/refresh tokens without exposing secrets to the browser.

Nuxt 3 specifics: SSR, middleware, and sessions

Nuxt 3 gives you routing middleware and server endpoints (server routes) that are ideal for authentication. Implement the token exchange on a server route (server-side) and set a secure, HttpOnly, SameSite=strict cookie containing a session identifier or encrypted token payload.

Why not store JWTs in localStorage? Because localStorage is accessible to JavaScript and therefore XSS-vulnerable. HttpOnly cookies prevent JS reading the token, which shifts the attack surface from XSS to CSRF. Mitigate CSRF by using SameSite=strict/lax or anti-CSRF tokens.

Middleware example pattern: a global or per-route middleware that checks for a valid session cookie via a server API endpoint (or by validating a session JWT). If missing/expired, initiate the redirect to the provider. Nuxt 3’s useFetch or server APIs make these checks straightforward and TypeScript-friendly.

Vue 3 SPA specifics: SDK, PKCE, and secure storage

For pure SPA (client-side only) with Vue 3, use the provider’s SDK (e.g., Logto docs) which typically handles PKCE and token renewal via silent refresh or refresh tokens. However, avoid localStorage for storing long-lived tokens.

Prefer one of the following for SPA token storage:

• In-memory storage + refresh on page load (works but loses session on full refresh)
• Secure cookie (via server-assisted exchange) — best if you can add a small backend.

If you must store tokens client-side, minimize risk by using short-lived access tokens, use refresh tokens with rotation (if provider supports), and enforce strict Content Security Policy and automatic XSS scanning.

Practical code sketches (where to place what)

1) Server endpoint: /api/auth/callback — exchanges code for tokens via POST to provider token endpoint. Store only a sessionId cookie, map sessionId to server-side tokens (in-memory cache, Redis, DB) and refresh transparently.

2) Middleware: middleware/auth.ts — checks session validity via server endpoint /api/auth/me. If unauthenticated, redirect to /api/auth/login which proxies the provider authorization URI (adds PKCE).

3) Logout: call /api/auth/logout — revoke tokens at provider (if supported), clear server session, and clear cookie. Provide client-side UX: immediate redirect to login or homepage.

Security checklist — quick wins

– Use Authorization Code + PKCE for public clients. For confidential clients (server apps), standard Authorization Code + client secret is fine.

– Prefer HttpOnly, Secure, SameSite cookies for sessions. Keep access tokens short-lived. Use refresh tokens with rotation where possible.

– Protect SSR endpoints with server-side validation, validate ID token using provider’s keys (JWKS), check nonce & audience claims, and ensure TLS everywhere.

Logto-specific notes and links

Logto provides a modern OIDC-compliant service and SDKs for both Vue and Nuxt. You can find detailed examples at the Logto docs: Logto documentation and an approachable tutorial showing how to add Logto to Nuxt 3 / Vue 3 apps: dev.to: Add authentication to Nuxt 3 and Vue 3 with Logto.

If you prefer provider-agnostic reference, read about OpenID Connect and OAuth2 flows (Auth0 and RFC docs are useful). Official Nuxt documentation for middleware and server routes is here: Nuxt 3 Docs. Vue 3 core concepts: Vue 3 Guide.

Use the provider’s SDK where it makes sense, but keep your auth boundary small and server-side for sensitive operations.

Common pitfalls and how to avoid them

Pitfall 1: storing tokens in localStorage — avoid unless fully mitigated. Pitfall 2: mixing SSR and client-only logic incorrectly, causing inconsistent login states on refresh. Pitfall 3: missing token validation on server (accepting any JWT that looks valid client-side).

Fixes: centralize validation in server endpoints, use secure cookies, and test flows with simulated network failures (refresh expiration scenarios). Also ensure your redirect URIs are exact and registered with the provider.

Finally, monitor suspicious requests and failed token exchanges; instrument your auth endpoints for telemetry and error logging.

Implementation mini-checklist (developer actionable)

• Decide SSR vs SPA: prefer SSR for critical apps that need secure sessions.
• Implement server-side callback and session cookie.
• Protect routes with middleware that validates session on server.
• Use PKCE + Authorization Code flow, validate tokens (iss, aud, exp, nonce).
• Implement logout with provider revocation and cookie clearing.

TypeScript tips

Type your server endpoints’ session payloads (user id, roles, expiry). Use zod or io-ts for runtime validation of tokens/claims. Define a single Auth module with typed functions: login(), callback(), me(), logout(). This reduces duplicates and keeps the auth flow auditable.

Keep interfaces small and explicit: UserSession { sub: string; name?: string; email?: string; exp: number } and treat any unknown claims cautiously.

When integrating SDKs, prefer the provider’s typed client or wrap it in a thin adapter to keep implementation details out of the rest of your app.

Wrap-up — recommended next steps

Pick one provider (Logto is a good modern choice), build the server callback and session handler first, then add middleware to protect routes, and finally wire the SDK on the client for optional client-side UX (profile/consent). Test thoroughly with expired tokens, revoked refresh tokens, and CSRF scenarios.

If you need a compact starter: create minimal server endpoints (/api/auth/login, /api/auth/callback, /api/auth/me, /api/auth/logout) and a middleware/auth.ts in Nuxt 3 that queries /api/auth/me before allowing access.

Good luck. If you want, I can generate a ready-to-drop-in Nuxt 3 starter with TypeScript and Logto wiring (server endpoints + middleware) — say the word.

Semantic core (clusters, LSI, intents)

Use the above keywords naturally in headings and body; avoid stuffing. Favor long-tail variants when answering specific sub-questions (e.g., “nuxt 3 login system with pkce”).

Popular user questions (PAA / forums) — source-inspired

Collected from People Also Ask / dev forums / tutorial headings (simulated):

1. How do I add authentication to Nuxt 3 with Logto?
2. How do I protect routes in Nuxt 3?
3. How should I store tokens in a Vue 3 SPA?
4. What is the difference between OAuth2 and OpenID Connect?
5. How do I implement login/logout flow with Nuxt 3?
6. How to refresh tokens safely in the browser?
7. How to implement server-side sessions in Nuxt 3?
8. How to validate ID tokens and check claims?

FAQ — top 3 (short, clear answers)

Q1: How do I add authentication to Nuxt 3 with Logto?

A1: Use Authorization Code + PKCE. Implement a server callback (/api/auth/callback) to exchange the code for tokens, store session info in a server-side store (or encrypted cookie), and set a Secure HttpOnly cookie. Use middleware to guard routes and redirect unauthenticated users to a login endpoint that initiates the Logto authorization redirect. For step-by-step examples, see the Logto docs: Logto docs and the tutorial: dev.to article.

Q2: How should I store tokens in a Vue 3 SPA?

A2: Prefer in-memory storage with short-lived tokens or, better, a server-side session (HttpOnly cookie) handled by a small backend. If you must store tokens client-side, avoid localStorage if possible; use short access token lifetimes and refresh tokens with rotation. Always combine with strict CSP and XSS mitigation.

Q3: How do I protect routes in Nuxt 3?

A3: Create a middleware that calls a server endpoint (/api/auth/me) to verify session validity. If the session is invalid or missing, redirect to your login endpoint. For SSR pages, evaluate the session server-side before rendering to avoid flicker and security gaps.