> ## Documentation Index
> Fetch the complete documentation index at: https://docs.didit.me/llms.txt
> Use this file to discover all available pages before exploring further.

# Next.js クイックスタート：Diditで認証を実装

> DiditのAuthenticationをNext.jsに導入する手順です。PKCEコールバックとHttpOnly Cookieでサーバー側がセッションを管理し、保護されたリクエストごとに認可を行います。

> [!WARNING]
>
> 認証機能は新機能です。`@didit-protocol/auth-nextjs`とコアのサーバー検証機能は、リリース状況に依存します。パッケージのリリース前の段階では、middlewareのインポートパス、Cookie名、`auth()`の戻り値の形はいずれも定められていません。アクセストークンはES256のJWTです。アプリケーションのJWKSで検証し、セッションがまだ有効であることを確認する必要がある場合は`GET session/`を呼び出してください。

## セッションをサーバー側で保持する

[JavaScriptクイックスタート](https://docs.didit.me/ja/authentication/quickstarts/javascript.md)で説明しているホスト型フローを使用し、サーバーレンダリングのアプリケーション向けに以下の変更を加えてください。ルート名はお客様が実装するアプリケーションのルートであり、DiditのAPIエンドポイントではありません。

| アプリケーションのルート | 役割 |
| - | - |
| サインインの開始 | stateとS256のPKCEを生成し、トランザクションを短期間のサーバーセッションに保存して、`{origin}/sign-in`にリダイレクトします。 |
| 登録済みのコールバック | stateと有効期限を検証し、トランザクションを一度だけ消費して、`token/`でコードを交換し、トークンをサーバー側に保存します。 |
| 保護されたページまたはAPIルート | セッションCookieを読み取り、エンドユーザーのアクセストークンをJWKSで検証します。失効を即時に反映する必要がある場合は`session/`で検証します。そのうえで、その人物に要求されたアクションを実行する権限があることを確認します。 |
| リフレッシュ | セッションごとにリフレッシュを直列化し、`token/`を呼び出して、トークンペアをアトミックに置き換えます。 |
| サインアウト | `session/`を失効させ、アプリケーションのセッションを消去する、CSRF対策を施した変更処理です。 |

Cookieには、ランダムなアプリケーションセッションの参照値のみを、`Secure`、`HttpOnly`、`SameSite=Lax`を指定し、パスを限定して送信してください。適切な有効期限を設定し、サインイン後に参照値をローテーションしてください。Diditのリフレッシュトークンを、レンダリングされるprops、クライアントコンポーネント、ブラウザのストレージに公開しないでください。トークンとコールバックのレスポンスには`Cache-Control: no-store`を使用してください。

レイアウトやmiddlewareでのチェックだけに頼らず、データへのアクセスと変更処理のたびに認可を行ってください。Cookieで認証する変更処理はCSRFから保護してください。ログイン後の遷移先は設定済みのものだけを許可し、クエリ文字列から渡された任意の`returnTo`のURLは決して許可しないでください。

## パッケージのリリースプレビュー

予定しているパッケージでは、サーバーレンダリング向けにmiddleware、サーバー側の`auth()`、コールバックルート、HttpOnly Cookieのサポートが追加されます。コアの`/server`エントリーは、キャッシュされたJWKSを使う`verifyToken()`を提供する予定です。これらのシンボルは、検証済みのリリースでエクスポートされるまで使用しないでください。それまでは、[トークンとJWKS](https://docs.didit.me/ja/authentication/tokens-and-jwks.md)で説明しているとおり、任意のJOSEライブラリを使って自分でトークンを検証してください。

## 他のプロダクトとの連携

認証セッションの作成と、スコープを限定したモニタリング用トークンの発行は、サーバー側で行ってください。`vendor_data`は、検証済みの人物マッピングから導出してください。ブラウザには、認証セッションのURLまたは短期間有効なSDKトークンのみを返してください。`DIDIT_API_KEY`は公開される環境変数に含めないでください。

認証には既存の[Web認証SDK](https://docs.didit.me/ja/integration/web-sdks/javascript-sdk.md)を、モニタリングには[取引送信ガイド](https://docs.didit.me/ja/transaction-monitoring/sdk-transaction-submission.md)を使用してください。どちらもAuthenticationのセッション管理機能ではありません。

リリース前に、コールバックのリプレイ、誤ったstate、期限切れのstate、リフレッシュの競合、失効したセッション、CSRFの拒否、ログアウトをテストしてください。検証の仕様については[トークンとJWKS](https://docs.didit.me/ja/authentication/tokens-and-jwks.md)を参照してください。


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.