Overview
重要なコンセプト
- 悪意のある攻撃からアプリケーションを保護するには、トークンの保管方法を慎重に決めることが肝心になる
- アプリケーションタイプ別のシナリオを確認する
- 使用しているテクノロジーに適した方法を選択する
Next.js静的サイトのシナリオ
Next.jsアプリケーションを構築する場合、次の場合に認証が必要になることがあります。- ページにアクセスする場合
- APIルートにアクセスする場合
- アプリケーションがユーザーに代わってNext.jsアプリケーション外でホストされたAPIを呼び出す場合
- ユーザーはAuth0にリダイレクトされます。
- ユーザーが正常にサインインすると、アプリケーションにリダイレクトされます。
-
クライアント側は Auth0 とのコード交換を完了し、ユーザーの
id_tokenとaccess_tokenを取得します。これらはメモリに保存されます。
- 従来のWebアプリ
- ネイティブ/モバイルアプリ
- シングルページアプリ
アプリがAPIの呼び出しを必要としないサインインシナリオを使用している場合、IDトークンのみが必要になります。保存する必要はありません。IDトークンを検証することができ、必要なときにそこからデータを取得することができます。アプリがユーザーの代わりにAPIを呼び出す必要がある場合、アクセストークンと（任意で）リフレッシュトークンが必要になります。これらは、サーバー側、またはセッションクッキーとして保存することができます。クッキーは暗号化され、最大サイズは4KBです。保存されるデータが大きい場合、セッションクッキーにトークンを保存することができません。これらのシナリオには次のフロータイプを使用します。
ブラウザのメモリ内シナリオ
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など）に存在する可能性があります。