認証
アプリケーションのデータを保護するためには、認証を理解することが重要です。このページでは、認証を実装するために使用するReactおよびNext.jsの機能について説明します。
始める前に、プロセスを3つの概念に分解すると役立ちます。
- 認証: ユーザーが主張する本人であることを確認します。ユーザー名とパスワードなど、ユーザーが所有するものを使って本人であることを証明する必要があります。
- セッション管理: リクエスト間でユーザーの認証状態を追跡します。
- 認可: ユーザーがアクセスできるルートとデータを決定します。
この図は、ReactとNext.jsの機能を使用した認証フローを示しています。

このページの例は、教育目的のために基本的なユーザー名とパスワードによる認証を説明しています。カスタム認証ソリューションを実装することも可能ですが、セキュリティとシンプルさを向上させるために、認証ライブラリの使用をお勧めします。これらは、認証、セッション管理、認可のための組み込みソリューションに加え、ソーシャルログイン、多要素認証、ロールベースのアクセス制御などの追加機能を提供します。リストは「認証ライブラリ」セクションにあります。
認証
サインアップとログイン機能
ReactのサーバーアクションとuseActionState
とともに<form>
要素を使用すると、ユーザー認証情報を取得し、フォームフィールドを検証し、認証プロバイダーのAPIまたはデータベースを呼び出すことができます。
サーバーアクションは常にサーバー上で実行されるため、認証ロジックを処理するための安全な環境を提供します。
サインアップ/ログイン機能を実装するための手順は次のとおりです。
1. ユーザー認証情報を取得する
ユーザー認証情報を取得するには、送信時にサーバーアクションを呼び出すフォームを作成します。たとえば、ユーザーの名前、メールアドレス、パスワードを受け入れるサインアップフォームなどです。
import { signup } from '@/app/actions/auth'
export function SignupForm() {
return (
<form action={signup}>
<div>
<label htmlFor="name">Name</label>
<input id="name" name="name" placeholder="Name" />
</div>
<div>
<label htmlFor="email">Email</label>
<input id="email" name="email" type="email" placeholder="Email" />
</div>
<div>
<label htmlFor="password">Password</label>
<input id="password" name="password" type="password" />
</div>
<button type="submit">Sign Up</button>
</form>
)
}
export async function signup(formData: FormData) {}
2. サーバーでフォームフィールドを検証する
サーバーアクションを使用して、サーバー上でフォームフィールドを検証します。認証プロバイダーがフォーム検証を提供していない場合は、ZodやYupのようなスキーマ検証ライブラリを使用できます。
Zodを例として、適切なエラーメッセージを含むフォームスキーマを定義できます。
import { z } from 'zod'
export const SignupFormSchema = z.object({
name: z
.string()
.min(2, { message: 'Name must be at least 2 characters long.' })
.trim(),
email: z.string().email({ message: 'Please enter a valid email.' }).trim(),
password: z
.string()
.min(8, { message: 'Be at least 8 characters long' })
.regex(/[a-zA-Z]/, { message: 'Contain at least one letter.' })
.regex(/[0-9]/, { message: 'Contain at least one number.' })
.regex(/[^a-zA-Z0-9]/, {
message: 'Contain at least one special character.',
})
.trim(),
})
export type FormState =
| {
errors?: {
name?: string[]
email?: string[]
password?: string[]
}
message?: string
}
| undefined
認証プロバイダーのAPIやデータベースへの不要な呼び出しを防ぐため、定義されたスキーマと一致しないフォームフィールドがある場合、サーバーアクションで早期にreturn
することができます。
import { SignupFormSchema, FormState } from '@/app/lib/definitions'
export async function signup(state: FormState, formData: FormData) {
// Validate form fields
const validatedFields = SignupFormSchema.safeParse({
name: formData.get('name'),
email: formData.get('email'),
password: formData.get('password'),
})
// If any form fields are invalid, return early
if (!validatedFields.success) {
return {
errors: validatedFields.error.flatten().fieldErrors,
}
}
// Call the provider or db to create a user...
}
<SignupForm />
に戻り、ReactのuseActionState
フックを使用して、フォーム送信中に検証エラーを表示できます。
'use client'
import { signup } from '@/app/actions/auth'
import { useActionState } from 'react'
export default function SignupForm() {
const [state, action, pending] = useActionState(signup, undefined)
return (
<form action={action}>
<div>
<label htmlFor="name">Name</label>
<input id="name" name="name" placeholder="Name" />
</div>
{state?.errors?.name && <p>{state.errors.name}</p>}
<div>
<label htmlFor="email">Email</label>
<input id="email" name="email" placeholder="Email" />
</div>
{state?.errors?.email && <p>{state.errors.email}</p>}
<div>
<label htmlFor="password">Password</label>
<input id="password" name="password" type="password" />
</div>
{state?.errors?.password && (
<div>
<p>Password must:</p>
<ul>
{state.errors.password.map((error) => (
<li key={error}>- {error}</li>
))}
</ul>
</div>
)}
<button disabled={pending} type="submit">
Sign Up
</button>
</form>
)
}
参考情報
- React 19では、
useFormStatus
は返されるオブジェクトにdata、method、actionなどの追加のキーを含みます。React 19を使用していない場合、pending
キーのみが利用可能です。- データを変更する前に、ユーザーがそのアクションを実行する権限を持っていることを常に確認する必要があります。認証と認可を参照してください。
3. ユーザーを作成するか、ユーザー認証情報を確認する
フォームフィールドを検証した後、認証プロバイダーのAPIまたはデータベースを呼び出すことにより、新しいユーザーアカウントを作成するか、ユーザーが存在するかどうかを確認できます。
前の例から続きます。
export async function signup(state: FormState, formData: FormData) {
// 1. Validate form fields
// ...
// 2. Prepare data for insertion into database
const { name, email, password } = validatedFields.data
// e.g. Hash the user's password before storing it
const hashedPassword = await bcrypt.hash(password, 10)
// 3. Insert the user into the database or call an Auth Library's API
const data = await db
.insert(users)
.values({
name,
email,
password: hashedPassword,
})
.returning({ id: users.id })
const user = data[0]
if (!user) {
return {
message: 'An error occurred while creating your account.',
}
}
// TODO:
// 4. Create user session
// 5. Redirect user
}
ユーザーアカウントの作成またはユーザー認証情報の検証が成功した後、ユーザーの認証状態を管理するためのセッションを作成できます。セッション管理戦略に応じて、セッションはCookieまたはデータベース、あるいはその両方に保存できます。詳細については、「セッション管理」セクションを参照してください。
ヒント
- 上記の例は、教育目的のために認証ステップを詳細に分解しているため、冗長です。これは、独自のセキュアなソリューションを実装することがすぐに複雑になる可能性があることを示しています。プロセスを簡素化するために、認証ライブラリの使用を検討してください。
- ユーザーエクスペリエンスを向上させるために、登録フローの早い段階で重複するメールアドレスやユーザー名をチェックすると良いでしょう。たとえば、ユーザーがユーザー名を入力しているときや、入力フィールドがフォーカスを失ったときなどです。これにより、不要なフォーム送信を防ぎ、ユーザーに即座にフィードバックを提供できます。これらのチェックの頻度を管理するために、use-debounceのようなライブラリでリクエストをデバウンスできます。
セッション管理
セッション管理は、ユーザーの認証状態がリクエスト間で保持されることを保証します。これには、セッションまたはトークンの作成、保存、更新、および削除が含まれます。
セッションには2つのタイプがあります。
- ステートレス: セッションデータ (またはトークン) はブラウザのCookieに保存されます。Cookieは各リクエストとともに送信され、サーバー上でセッションを検証できます。この方法はより単純ですが、正しく実装されていない場合はセキュリティが低下する可能性があります。
- データベース: セッションデータはデータベースに保存され、ユーザーのブラウザは暗号化されたセッションIDのみを受け取ります。この方法はより安全ですが、複雑でより多くのサーバーリソースを使用する可能性があります。
参考情報: どちらの方法、または両方を使用できますが、iron-sessionやJoseのようなセッション管理ライブラリの使用をお勧めします。
ステートレスセッション
ステートレスセッションを作成および管理するには、いくつかの手順に従う必要があります。
- セッションの署名に使用する秘密鍵を生成し、環境変数として保存します。
- セッション管理ライブラリを使用してセッションデータを暗号化/復号するロジックを作成します。
- Next.jsの
cookies
APIを使用してCookieを管理します。
上記に加えて、ユーザーがアプリケーションに戻ったときにセッションを更新 (またはリフレッシュ) する機能、およびユーザーがログアウトしたときにセッションを削除する機能を追加することを検討してください。
参考情報: 使用している認証ライブラリにセッション管理機能が含まれているか確認してください。
1. 秘密鍵を生成する
セッションに署名するための秘密鍵を生成する方法はいくつかあります。たとえば、ターミナルでopenssl
コマンドを使用することを選択できます。
openssl rand -base64 32
このコマンドは、秘密鍵として使用し、環境変数ファイルに保存できる32文字のランダムな文字列を生成します。
SESSION_SECRET=your_secret_key
その後、セッション管理ロジックでこのキーを参照できます。
const secretKey = process.env.SESSION_SECRET
2. セッションの暗号化と復号
次に、お好みのセッション管理ライブラリを使用してセッションを暗号化および復号できます。前の例から引き続き、Jose (Edge Runtimeと互換性あり) とReactのserver-only
パッケージを使用して、セッション管理ロジックがサーバー上でのみ実行されるようにします。
import 'server-only'
import { SignJWT, jwtVerify } from 'jose'
import { SessionPayload } from '@/app/lib/definitions'
const secretKey = process.env.SESSION_SECRET
const encodedKey = new TextEncoder().encode(secretKey)
export async function encrypt(payload: SessionPayload) {
return new SignJWT(payload)
.setProtectedHeader({ alg: 'HS256' })
.setIssuedAt()
.setExpirationTime('7d')
.sign(encodedKey)
}
export async function decrypt(session: string | undefined = '') {
try {
const { payload } = await jwtVerify(session, encodedKey, {
algorithms: ['HS256'],
})
return payload
} catch (error) {
console.log('Failed to verify session')
}
}
ヒント:
- ペイロードには、ユーザーID、ロールなど、以降のリクエストで使用される最小限の固有のユーザーデータを含める必要があります。電話番号、メールアドレス、クレジットカード情報などの個人を特定できる情報や、パスワードなどの機密データを含めるべきではありません。
3. Cookieの設定 (推奨オプション)
セッションをCookieに保存するには、Next.jsのcookies
APIを使用します。Cookieはサーバー上で設定し、推奨オプションを含める必要があります。
- HttpOnly: クライアントサイドのJavaScriptがCookieにアクセスするのを防ぎます。
- Secure: httpsを使用してCookieを送信します。
- SameSite: クロスサイトリクエストでCookieを送信できるかどうかを指定します。
- Max-AgeまたはExpires: 一定期間後にCookieを削除します。
- Path: CookieのURLパスを定義します。
これらの各オプションの詳細については、MDNを参照してください。
import 'server-only'
import { cookies } from 'next/headers'
export async function createSession(userId: string) {
const expiresAt = new Date(Date.now() + 7 * 24 * 60 * 60 * 1000)
const session = await encrypt({ userId, expiresAt })
const cookieStore = await cookies()
cookieStore.set('session', session, {
httpOnly: true,
secure: true,
expires: expiresAt,
sameSite: 'lax',
path: '/',
})
}
サーバーアクションに戻り、createSession()
関数を呼び出し、redirect()
APIを使用してユーザーを適切なページにリダイレクトできます。
import { createSession } from '@/app/lib/session'
export async function signup(state: FormState, formData: FormData) {
// Previous steps:
// 1. Validate form fields
// 2. Prepare data for insertion into database
// 3. Insert the user into the database or call an Library API
// Current steps:
// 4. Create user session
await createSession(user.id)
// 5. Redirect user
redirect('/profile')
}
ヒント:
- Cookieはクライアントサイドでの改ざんを防ぐため、サーバー上で設定する必要があります。
- 🎥 視聴: Next.jsを使用したステートレスセッションと認証についてさらに学ぶ → YouTube (11分)。
セッションの更新 (またはリフレッシュ)
セッションの有効期限を延長することもできます。これは、ユーザーがアプリケーションに再度アクセスした後もログイン状態を維持するのに役立ちます。例えば、
import 'server-only'
import { cookies } from 'next/headers'
import { decrypt } from '@/app/lib/session'
export async function updateSession() {
const session = (await cookies()).get('session')?.value
const payload = await decrypt(session)
if (!session || !payload) {
return null
}
const expires = new Date(Date.now() + 7 * 24 * 60 * 60 * 1000)
const cookieStore = await cookies()
cookieStore.set('session', session, {
httpOnly: true,
secure: true,
expires: expires,
sameSite: 'lax',
path: '/',
})
}
ヒント: 認証ライブラリがリフレッシュトークンをサポートしているか確認してください。これはユーザーのセッションを延長するために使用できます。
セッションの削除
セッションを削除するには、Cookieを削除できます。
import 'server-only'
import { cookies } from 'next/headers'
export async function deleteSession() {
const cookieStore = await cookies()
cookieStore.delete('session')
}
その後、アプリケーションでdeleteSession()
関数を再利用できます。例えば、ログアウト時などです。
import { cookies } from 'next/headers'
import { deleteSession } from '@/app/lib/session'
export async function logout() {
deleteSession()
redirect('/login')
}
データベースセッション
データベースセッションを作成および管理するには、次の手順に従う必要があります。
- セッションとデータを保存するためのテーブルをデータベースに作成します (または、使用している認証ライブラリがこれを処理するか確認します)。
- セッションを挿入、更新、削除する機能を実装します。
- セッションIDをユーザーのブラウザに保存する前に暗号化し、データベースとCookieが同期していることを確認します (これはオプションですが、ミドルウェアでの楽観的な認証チェックには推奨されます)。
例えば、
import cookies from 'next/headers'
import { db } from '@/app/lib/db'
import { encrypt } from '@/app/lib/session'
export async function createSession(id: number) {
const expiresAt = new Date(Date.now() + 7 * 24 * 60 * 60 * 1000)
// 1. Create a session in the database
const data = await db
.insert(sessions)
.values({
userId: id,
expiresAt,
})
// Return the session ID
.returning({ id: sessions.id })
const sessionId = data[0].id
// 2. Encrypt the session ID
const session = await encrypt({ sessionId, expiresAt })
// 3. Store the session in cookies for optimistic auth checks
const cookieStore = await cookies()
cookieStore.set('session', session, {
httpOnly: true,
secure: true,
expires: expiresAt,
sameSite: 'lax',
path: '/',
})
}
ヒント:
- より高速なデータ取得のために、Vercel Redisのようなデータベースの使用を検討してください。ただし、セッションデータをプライマリデータベースに保持し、データリクエストを結合してクエリの数を減らすこともできます。
- ユーザーが最後にログインした時刻やアクティブなデバイスの数を追跡したり、ユーザーがすべてのデバイスからログアウトできるようにするなど、より高度なユースケースでデータベースセッションを使用することを選択できます。
セッション管理を実装したら、ユーザーがアプリケーション内でアクセスできるものと実行できるものを制御するための認可ロジックを追加する必要があります。詳細については、「認可」セクションに進んでください。
認可
ユーザーが認証され、セッションが作成されたら、認可を実装して、ユーザーがアプリケーション内でアクセスできるものと実行できるものを制御できます。
認可チェックには主に2つのタイプがあります。
- 楽観的: Cookieに保存されたセッションデータを使用して、ユーザーがルートにアクセスしたりアクションを実行したりする権限があるかどうかを確認します。これらのチェックは、UI要素の表示/非表示や、権限またはロールに基づいてユーザーをリダイレクトするなど、迅速な操作に役立ちます。
- セキュア: データベースに保存されたセッションデータを使用して、ユーザーがルートにアクセスしたりアクションを実行したりする権限があるかどうかを確認します。これらのチェックはより安全であり、機密データへのアクセスやアクションを必要とする操作に使用されます。
どちらの場合も、推奨されるのは次のとおりです。
- 認可ロジックを一元化するためのデータアクセスレイヤーの作成
- 必要なデータのみを返すデータ転送オブジェクト (DTO) の使用
- オプションで、ミドルウェアを使用して楽観的なチェックを実行します。
ミドルウェアによる楽観的なチェック (オプション)
ミドルウェアを使用し、権限に基づいてユーザーをリダイレクトしたいケースがいくつかあります。
- 楽観的なチェックを実行するため。ミドルウェアはすべてのルートで実行されるため、リダイレクトロジックを一元化し、未認可のユーザーを事前にフィルタリングするのに良い方法です。
- ユーザー間でデータを共有する静的ルート (例: ペイウォールのコンテンツ) を保護するため。
ただし、ミドルウェアはプリフェッチされたルートを含むすべてのルートで実行されるため、パフォーマンスの問題を防ぐために、セッションをCookieからのみ読み取り (楽観的なチェック)、データベースチェックを避けることが重要です。
例えば、
import { NextRequest, NextResponse } from 'next/server'
import { decrypt } from '@/app/lib/session'
import { cookies } from 'next/headers'
// 1. Specify protected and public routes
const protectedRoutes = ['/dashboard']
const publicRoutes = ['/login', '/signup', '/']
export default async function middleware(req: NextRequest) {
// 2. Check if the current route is protected or public
const path = req.nextUrl.pathname
const isProtectedRoute = protectedRoutes.includes(path)
const isPublicRoute = publicRoutes.includes(path)
// 3. Decrypt the session from the cookie
const cookie = (await cookies()).get('session')?.value
const session = await decrypt(cookie)
// 4. Redirect to /login if the user is not authenticated
if (isProtectedRoute && !session?.userId) {
return NextResponse.redirect(new URL('/login', req.nextUrl))
}
// 5. Redirect to /dashboard if the user is authenticated
if (
isPublicRoute &&
session?.userId &&
!req.nextUrl.pathname.startsWith('/dashboard')
) {
return NextResponse.redirect(new URL('/dashboard', req.nextUrl))
}
return NextResponse.next()
}
// Routes Middleware should not run on
export const config = {
matcher: ['/((?!api|_next/static|_next/image|.*\\.png$).*)'],
}
ミドルウェアは初期チェックに役立ちますが、データの保護における唯一の防御線であってはなりません。セキュリティチェックの大部分は、データソースのできるだけ近くで実行されるべきです。詳細については、「データアクセスレイヤー」を参照してください。
ヒント:
- ミドルウェアでは、
req.cookies.get('session').value
を使用してCookieを読み取ることもできます。- ミドルウェアはEdge Runtimeを使用します。使用している認証ライブラリとセッション管理ライブラリが互換性があるか確認してください。
- ミドルウェアの
matcher
プロパティを使用して、ミドルウェアを実行するルートを指定できます。ただし、認証の場合は、ミドルウェアをすべてのルートで実行することが推奨されます。
データアクセスレイヤー (DAL) の作成
データリクエストと認可ロジックを一元化するために、DALを作成することをお勧めします。
DALには、ユーザーがアプリケーションとやり取りする際にセッションを検証する関数が含まれている必要があります。少なくとも、その関数はセッションが有効であるかを確認し、その後リダイレクトするか、さらなるリクエストを行うのに必要なユーザー情報を返すべきです。
例えば、verifySession()
関数を含むDAL用の別のファイルを作成します。次に、Reactのcache APIを使用して、Reactレンダリングパス中にその関数の戻り値をメモ化します。
import 'server-only'
import { cookies } from 'next/headers'
import { decrypt } from '@/app/lib/session'
export const verifySession = cache(async () => {
const cookie = (await cookies()).get('session')?.value
const session = await decrypt(cookie)
if (!session?.userId) {
redirect('/login')
}
return { isAuth: true, userId: session.userId }
})
その後、データリクエスト、サーバーアクション、ルートハンドラーでverifySession()
関数を呼び出すことができます。
export const getUser = cache(async () => {
const session = await verifySession()
if (!session) return null
try {
const data = await db.query.users.findMany({
where: eq(users.id, session.userId),
// Explicitly return the columns you need rather than the whole user object
columns: {
id: true,
name: true,
email: true,
},
})
const user = data[0]
return user
} catch (error) {
console.log('Failed to fetch user')
return null
}
})
ヒント:
- DALはリクエスト時にフェッチされるデータを保護するために使用できます。ただし、ユーザー間でデータを共有する静的ルートの場合、データはリクエスト時ではなくビルド時にフェッチされます。静的ルートを保護するにはミドルウェアを使用してください。
- セキュアなチェックを行うには、セッションIDをデータベースと比較してセッションが有効であるかを確認できます。Reactのcache関数を使用して、レンダリングパス中のデータベースへの不要な重複リクエストを避けてください。
- 関連するデータリクエストを、メソッドの前に
verifySession()
を実行するJavaScriptクラスに統合することもできます。
データ転送オブジェクト (DTO) の使用
データを取得する際は、アプリケーションで使用される必要なデータのみを返し、オブジェクト全体を返さないことをお勧めします。たとえば、ユーザーデータをフェッチする場合、パスワードや電話番号などを含むユーザーオブジェクト全体ではなく、ユーザーIDと名前のみを返すことができます。
ただし、返されるデータ構造を制御できない場合や、オブジェクト全体がクライアントに渡されるのを避けたいチームで作業している場合は、クライアントに公開しても安全なフィールドを指定するなどの戦略を使用できます。
import 'server-only'
import { getUser } from '@/app/lib/dal'
function canSeeUsername(viewer: User) {
return true
}
function canSeePhoneNumber(viewer: User, team: string) {
return viewer.isAdmin || team === viewer.team
}
export async function getProfileDTO(slug: string) {
const data = await db.query.users.findMany({
where: eq(users.slug, slug),
// Return specific columns here
})
const user = data[0]
const currentUser = await getUser(user.id)
// Or return only what's specific to the query here
return {
username: canSeeUsername(currentUser) ? user.username : null,
phonenumber: canSeePhoneNumber(currentUser, user.team)
? user.phonenumber
: null,
}
}
データリクエストと認可ロジックをDALに一元化し、DTOを使用することで、すべてのデータリクエストが安全かつ一貫していることを保証でき、アプリケーションの規模が拡大しても、保守、監査、デバッグが容易になります。
参考情報:
- DTOを定義する方法はいくつかあり、
toJSON()
を使用する方法、上記の例のような個別の関数、またはJSクラスなどがあります。これらはJavaScriptのパターンであり、ReactやNext.jsの機能ではないため、ご自身のアプリケーションに最適なパターンを見つけるために調査することをお勧めします。- セキュリティのベストプラクティスについては、弊社の「Security in Next.js」記事で詳細をご覧ください。
サーバーコンポーネント
サーバーコンポーネントでの認証チェックは、ロールベースのアクセスに役立ちます。例えば、ユーザーのロールに基づいてコンポーネントを条件付きでレンダリングする場合などです。
import { verifySession } from '@/app/lib/dal'
export default function Dashboard() {
const session = await verifySession()
const userRole = session?.user?.role // Assuming 'role' is part of the session object
if (userRole === 'admin') {
return <AdminDashboard />
} else if (userRole === 'user') {
return <UserDashboard />
} else {
redirect('/login')
}
}
この例では、DALのverifySession()
関数を使用して、「admin」、「user」、および未承認のロールをチェックしています。このパターンにより、各ユーザーが自分のロールに適したコンポーネントのみとやり取りすることが保証されます。
レイアウトと認証チェック
部分レンダリングのため、レイアウトでのチェックには注意が必要です。レイアウトはナビゲーション時に再レンダリングされないため、ルート変更ごとにユーザーセッションがチェックされないことを意味します。
その代わりに、データソースの近く、または条件付きでレンダリングされるコンポーネントでチェックを行うべきです。
例えば、ユーザーデータをフェッチし、ナビゲーションにユーザー画像を表示する共有レイアウトを考えます。レイアウトで認証チェックを行う代わりに、レイアウトでユーザーデータをフェッチし (getUser()
)、DALで認証チェックを行うべきです。
これにより、アプリケーション内でgetUser()
が呼び出される場所であればどこでも認証チェックが実行されることが保証され、開発者がデータへのアクセス権限をチェックし忘れることを防ぎます。
export default async function Layout({
children,
}: {
children: React.ReactNode;
}) {
const user = await getUser();
return (
// ...
)
}
export const getUser = cache(async () => {
const session = await verifySession()
if (!session) return null
// Get user ID from session and fetch data
})
参考情報
- SPAでよく見られるパターンは、ユーザーが認可されていない場合にレイアウトまたはトップレベルコンポーネントで
return null
を使用することです。このパターンは、Next.jsアプリケーションには複数のエントリーポイントがあり、ネストされたルートセグメントやサーバーアクションへのアクセスを防ぐことができないため、推奨されません。
サーバーアクション
サーバーアクションは、公開されているAPIエンドポイントと同じセキュリティ上の考慮事項を持って扱い、ユーザーがミューテーションを実行する権限があるかどうかを確認してください。
以下の例では、アクションを進める前にユーザーのロールをチェックしています。
'use server'
import { verifySession } from '@/app/lib/dal'
export async function serverAction(formData: FormData) {
const session = await verifySession()
const userRole = session?.user?.role
// Return early if user is not authorized to perform the action
if (userRole !== 'admin') {
return null
}
// Proceed with the action for authorized users
}
ルートハンドラ
ルートハンドラは、公開されているAPIエンドポイントと同じセキュリティ上の考慮事項を持って扱い、ユーザーがルートハンドラにアクセスする権限があるかどうかを確認してください。
例えば、
import { verifySession } from '@/app/lib/dal'
export async function GET() {
// User authentication and role verification
const session = await verifySession()
// Check if the user is authenticated
if (!session) {
// User is not authenticated
return new Response(null, { status: 401 })
}
// Check if the user has the 'admin' role
if (session.user.role !== 'admin') {
// User is authenticated but does not have the right permissions
return new Response(null, { status: 403 })
}
// Continue for authorized users
}
上記の例は、2段階のセキュリティチェックを備えたルートハンドラを示しています。最初にアクティブなセッションをチェックし、次にログイン中のユーザーが「admin」であるかを確認します。
コンテキストプロバイダー
認証のためのコンテキストプロバイダーの使用は、インターリービングによって機能します。ただし、Reactのcontext
はサーバーコンポーネントではサポートされていないため、クライアントコンポーネントにのみ適用されます。
これは機能しますが、子サーバーコンポーネントは最初にサーバー上でレンダリングされ、コンテキストプロバイダーのセッションデータにアクセスできません。
import { ContextProvider } from 'auth-lib'
export default function RootLayout({ children }) {
return (
<html lang="en">
<body>
<ContextProvider>{children}</ContextProvider>
</body>
</html>
)
}
"use client";
import { useSession } from "auth-lib";
export default function Profile() {
const { userId } = useSession();
const { data } = useSWR(`/api/user/${userId}`, fetcher)
return (
// ...
);
}
クライアントコンポーネントでセッションデータが必要な場合 (例: クライアントサイドでのデータフェッチの場合) は、ReactのtaintUniqueValue
APIを使用して、機密性の高いセッションデータがクライアントに公開されるのを防ぎます。
リソース
Next.jsでの認証について学んだところで、安全な認証とセッション管理を実装するのに役立つNext.js互換のライブラリとリソースを以下に示します。
認証ライブラリ
セッション管理ライブラリ
参考文献
認証とセキュリティについてさらに学ぶには、以下のリソースを参照してください。
これは役に立ちましたか?