トークンストレージ
Overview
重要なコンセプト
悪意のある攻撃からアプリケーションを保護するには、トークンの保管方法を慎重に決めることが肝心になる
アプリケーションタイプ別のシナリオを確認する
使用しているテクノロジーに適した方法を選択する
APIを呼び出すSPAのセキュリティ確保には、さまざまな懸念が伴います。トークンその他の極秘データが、クロスサイトスクリプティング（XSS）の脆弱性を持たないこと、悪意のあるJavaScriptによって解読される可能性がないことを保証する必要があります。
詳細については、JWTハンドブックおよびAuth0を使用したNext.js認証の究極ガイドを参照してください。
Next.js静的サイトのシナリオ
Next.jsアプリケーションを構築する場合、次の場合に認証が必要になることがあります。
ページにアクセスする場合
APIルートにアクセスする場合
アプリケーションがユーザーに代わってNext.jsアプリケーション外でホストされたAPIを呼び出す場合
サーバーが利用可能な場合、アプリはAuth0とのやり取りを処理してセッションを作成できますが、このモデルではバックエンドはありません。すべての作業はフロントエンドで行われます。
ユーザーはAuth0にリダイレクトされます。
ユーザーが正常にサインインすると、アプリケーションにリダイレクトされます。
クライアント側は Auth0 とのコード交換を完了し、ユーザーの
id_tokenとaccess_tokenを取得します。これらはメモリに保存されます。
アプリがAPIの呼び出しを必要としないサインインシナリオを使用している場合、IDトークンのみが必要になります。保存する必要はありません。IDトークンを検証することができ、必要なときにそこからデータを取得することができます。
アプリがユーザーの代わりにAPIを呼び出す必要がある場合、アクセストークンと（任意で）リフレッシュトークンが必要になります。これらは、サーバー側、またはセッションクッキーとして保存することができます。クッキーは暗号化され、最大サイズは4KBです。保存されるデータが大きい場合、セッションクッキーにトークンを保存することができません。
これらのシナリオには次のフロータイプを使用します。
OSが提供する安全なストレージにトークンを保存し、ストレージへのアクセスを制限します。たとえば、Android用のKeyStoreまたはiOS用のKeyChainを活用します。
これらのシナリオには次のフロータイプを使用します。
トークン保存やセッション管理、その他の詳細に対処するには、Auth0 SPA SDKの使用をお勧めします。
SPAが、そのドメインとクッキーを共有できるドメインから提供されるAPIのみを呼び出す場合、トークンは必要ありません。OAuthは、追加値を提供せずに攻撃ベクトルを増やすため、従来のクッキーを用いたアプローチを優先し、避けるべきです。
SPAが異なるドメインにある複数のAPIを呼び出す場合、アクセストークンと、必要に応じてリフレッシュトークンが必要です。
SPAのバックエンドがAPI呼び出しを処理できる場合、それは以下の方法でトークンをサーバー側で処理する従来のWebアプリケーションのように機能します。
SPAのバックエンドがAPI呼び出しを処理できない場合、モバイルアプリケーションのようにトークンをSPAのバックエンドに保存しますが、SPAはAPIへの要求を行うためにバックエンドからトークンを取得する必要があります。バックエンドとSPAの間で、トークンをバックエンドからSPAへ安全に転送するためのプロトコルを確立する必要があります。
対応するバックエンドサーバーがないSPAの場合、ログイン時に新しいトークンを要求し、それらをメモリ内に保存しますが、永続的に保存しないようにします。APIの呼び出しを行うには、SPAがトークンのインメモリコピーを使用します。
OAuth2の仕様に準拠して、ブラウザーが/tokenエンドポイントからリフレッシュトークンを要求したとき、Auth0は、そのクライアントに対してリフレッシュトークンのローテーションが有効になっている場合のみリフレッシュトークンを返します。
詳細については、「GitHubのAuth0 SPA SDK」を参照してください。
ブラウザのメモリ内シナリオ
Auth0は、最も安全なオプションとして、トークンをブラウザのメモリに保存することを推奨しています。Web Workersはアプリケーションの他の部分とは別のグローバルスコープで実行されるため、トークンの送信と保存を処理するためにWeb Workersを使用するのがトークンを保護する最善の方法です。デフォルトのストレージオプションがWeb Workersを活用したメモリ内ストレージであるAuth0 SPA SDKを使用します。
Web Workersを使用できない場合、Auth0では、代わりにJavaScriptクロージャを使用してプライベートメソッドをエミュレートすることを推奨しています。
デフォルトのストレージオプションがメモリ内ストレージであるAuth0 SPA SDKを使用して、トークンの種類に応じてWeb WorkersとJavaScriptクロージャの両方を活用します。
ブラウザーのメモリ内に保管する方法では、ページの更新やブラウザーのタブ間で永続しません。
ブラウザーローカルストレージのシナリオ
ブラウザーローカルストレージの使用は、iframeからアクセス トークンを取得する必要があるメカニズムや、ブラウザーの制限（ITP2など）によりドメイン間でCookieベースの認証が不可能な場合に、有効な代替手段となります。
ブラウザーのローカルストレージにトークンを保管すると、ページが更新されても、ブラウザータブが切り替わっても、持続性を確保できるというメリットがあります。しかし、攻撃者がクロスサイトスクリプティング（XSS）によってSPAでJavaScriptを実行できるようになると、ローカルストレージに保管されているトークンを取得されてしまいます。XSS攻撃の成功につながる脆弱性は、SPAソースコード、またはSPAに含まれるサードパーティのJavaScriptコード（ブートストラップ・jQuery・Google Analyticsなど）に存在する可能性があります。
SPAが暗黙的（代わりにPKCEを使用した認証コードフローの使用を推奨）またはハイブリッドフローを使用している場合、セキュリティリスクを軽減するために、絶対トークン有効期限を短縮できます。これにより、反映されたXSS攻撃の影響が軽減されます（ただし、永続的な攻撃の影響は軽減されません）。有効期限を短縮するには、ダッシュボード > API > Settings（設定） > Token Expiration For Browser Flows (Seconds)（ブラウザーフローのトークン有効期限切れ（秒））に移動します。
ドメイン外のソースから含まれるサードパーティJavaScriptコードの量を必要最小限に減らします（jQuery、Bootstrap、Google Analytics へのリンクなど）。サードパーティのJSコードを減らすと、XSS脆弱性の可能性が減ります。可能な場合は、サードパーティスクリプトでサブリソース整合性（SRI）チェックを実行して、取得されたリソースが予期しない操作なしで配信されていることを確認すると、より安全になります。