概要 重要なポイント
トークンの保存方法の選択は、悪意のある攻撃からアプリケーションを守るうえで非常に重要です。
アプリケーションの種類ごとのシナリオを確認します。
使用している技術に最も適した方法を選びます。
API 呼び出しを行う SPA の保護には、特有の注意点があります。トークンやその他の機密データが クロスサイトスクリプティング (XSS) の影響を受けず、悪意のある JavaScript に読み取られないようにする必要があります。
詳しくは、JWT Handbook および The Ultimate Guide to Next.js Authentication with Auth0 を参照してください。
Next.js アプリケーションを構築する際、次のような場合に認証が必要になることがあります。
ページにアクセスするとき
API ルートにアクセスするとき
アプリケーションがユーザーに代わって、Next.js アプリケーションの外部でホストされている API を呼び出すとき
サーバーを利用できる場合、アプリで Auth0 とのやり取りを処理してセッションを作成できますが、このモデルにはバックエンドがありません。すべての処理はフロントエンドで行われます。
ユーザーは Auth0 にリダイレクトされます。
ユーザーが正常にサインインすると、アプリケーションにリダイレクトされます。
クライアント側で Auth0 とのコード交換を完了し、ユーザーの id_token と access_token を取得してメモリに保存します。
従来型のウェブアプリ
ネイティブ/モバイルアプリ
シングルページアプリ
アプリで API 呼び出しを必要としないサインインのシナリオを使用する場合、必要なのは IDトークンのみです。これを保存する必要はありません。検証したうえで、必要なデータをそこから取得できます。 アプリがユーザーに代わって API を呼び出す必要がある場合は、アクセストークンと、必要に応じてリフレッシュトークンが必要です。これらはサーバー側またはセッションクッキーに保存できます。クッキーは暗号化されている必要があり、最大サイズは 4 KB です。保存するデータが大きい場合、セッションクッキーにトークンを保存する方法は現実的ではありません。 これらのシナリオでは、次のフロータイプを使用します。 OS が提供する安全な保存領域にトークンを保存し、その保存領域へのアクセスを制限します。たとえば、Android では KeyStore、iOS では KeyChain を活用します。 これらのシナリオでは、次のフロータイプを使用します。 トークンの保存、セッション管理、その他の処理を行うには、Auth0 SPA SDK の使用を推奨します。 SPA が、SPA のドメインとクッキーを共有できるドメインで提供される API だけを呼び出す場合、トークンは不要です。OAuth は追加の価値をもたらさない一方で攻撃ベクトルを増やすため、従来のクッキーベースのアプローチを優先し、使用は避けるべきです。 SPA が別のドメインに存在する複数の API を呼び出す場合は、アクセストークンと、必要に応じてリフレッシュトークンが必要です。
SPA のバックエンドが API 呼び出しを処理できる場合は、次を使用してサーバー側でトークンを処理する従来型のウェブアプリケーションと同様に機能します。
SPA のバックエンドが API 呼び出しを処理できない場合は、トークンを SPA バックエンドに保存するモバイルアプリケーションと同様に機能しますが、API へのリクエストを実行するには、SPA がバックエンドからトークンを取得する必要があります。バックエンドから SPA へトークンを安全に転送できるようにするため、バックエンドと SPA の間でプロトコルを確立する必要があります。
対応するバックエンドサーバーがない SPA の場合、SPA はログイン時に新しいトークンをリクエストし、永続化せずにメモリに保存する必要があります。その後 API 呼び出しを行う際は、SPA はメモリ内のトークンのコピーを使用します。
OAuth2 の仕様に準拠し、ブラウザーが /token エンドポイントにリフレッシュトークンをリクエストした場合、Auth0 はそのクライアントで Refresh Token Rotation が有効になっているときにのみリフレッシュトークンを返します。 詳細については、Auth0 SPA SDK in GitHub を参照してください。 Auth0 では、最も安全な方法として、ブラウザーのメモリーにトークンを保存することを推奨しています。トークンの送受信と保存の処理に Web Workers を使用するのが、トークンを保護する最善の方法です。Web Workers は、アプリケーションの他の部分とは分離されたグローバルスコープで実行されるためです。デフォルトの保存オプションとして、Web Workers を活用したインメモリー保存を採用している Auth0 SPA SDK を使用してください。
Web Workers を使用できない場合は、代替手段として、JavaScript クロージャ を使ってプライベートメソッドを擬似的に実現することを Auth0 では推奨しています。
トークンの種類に応じて Web Workers と JavaScript クロージャの両方を活用するには、デフォルトの保存オプションがインメモリー保存である Auth0 SPA SDK を使用してください。
ブラウザーでのインメモリー保存方式では、ページを再読み込みした場合や、ブラウザーのタブをまたいだ場合の永続性はありません 。
ブラウザーのローカルストレージの使用は、iframe から アクセストークン
ブラウザーのローカルストレージにトークンを保存すると、ページの再読み込み後や別のブラウザータブでも保持できますが、攻撃者がクロスサイトスクリプティング (XSS) 攻撃によって SPA 上で JavaScript を実行できる場合、ローカルストレージに保存されたトークンを取得されるおそれがあります。XSS 攻撃を成立させる脆弱性は、SPA のソースコード内にある場合もあれば、SPA に含まれているサードパーティの JavaScript コード (Bootstrap、jQuery、Google Analytics など) 内にある場合もあります。
SPA で implicit フローまたは hybrid フローを使用している場合は (代わりに PKCE を使用した Authorization Code フローの使用を推奨します) 、セキュリティリスクを軽減するために、トークンの絶対有効期限を短くできます。これにより、反射型 XSS 攻撃の影響は軽減されます (ただし、持続型 XSS 攻撃には効果がありません) 。有効期限を短くするには、Auth0 Dashboard > APIs > Settings > Token Expiration For Browser Flows (Seconds) に移動します。
ドメイン外のソースから読み込むサードパーティの JavaScript コードは、必要最小限 (jQuery、Bootstrap、Google Analytics などへのリンクなど) に抑えてください。サードパーティの JS コードを減らすことで、XSS 脆弱性が生じる可能性を低減できます。また、取得したリソースが予期しない改変を受けずに配信されていることを確認するため、可能な場合はサードパーティのスクリプトに対して Subresource Integrity (SRI) チェックを実施することも、セキュリティ向上につながります。
認証
ユーザー管理
カスタマイズ
プラットフォーム