ブラウザー認証

ブラウザー認証は、アプリケーションリクエストをユーザーまたはワークロードの アイデンティティに割り当てます。アプリケーションは、認証情報をどこに置くか、どの リクエストに認証情報を付与するか、ブラウザーがどのように制限するか、サーバーが どのように無効化するかを定義する必要があります。

セッションと Cookie #

同一サイトのバックエンドを持つブラウザーアプリケーションでは、Cookie 内の不透明な セッション識別子により、認証情報を JavaScript から隔離できます。セッション状態は サーバー側に保存し、認証後と権限変更後に識別子をローテーションし、ログアウト時と 非アクティブ時に期限切れにしてください。

Secure、HttpOnly、適切な SameSite 値を設定します。Secure は HTTPS を要求し、 HttpOnly は JavaScript からのアクセスを防ぎ、SameSite はクロスサイトリクエスト フォージェリへの露出を低減します。SameSite は CSRF 防御の代わりにはなりません。 状態を変更する Cookie 認証エンドポイントでは、CSRF トークンを検証するか、アプリケーション が明示的に信頼するオリジンを要求してください。

OAuth 2.0 と OpenID Connect #

OAuth 2.0 は認可を認可サーバーに委譲しますが、それ自体はユーザー認証を標準化しません。 OpenID Connect はアイデンティティ層と ID トークンを追加します。ブラウザーベースの パブリッククライアントでは、Authorization Code with PKCE を使用し、OpenID Connect 使用時の state、nonce、完全一致するリダイレクト URI、issuer、audience、有効期限、 署名を検証してください。

アクセス トークンを、ログ、リファラー、ブラウザー履歴に到達する可能性がある URL クエリ文字列やフラグメントに入れないでください。Backend-for-Frontend はトークンを サーバー上に保持し、ブラウザーにはアプリケーションのセッション Cookie を公開できます。

SAML #

SAML は、アイデンティティプロバイダーとサービスプロバイダーの間で署名付き XML アサーションを交換します。構成済みメタデータに対してアサーション署名を検証し、 issuer、audience、recipient、時刻条件、リクエスト相関を検証してください。XML 署名の 検証には保守されているライブラリと強化されたパーサーを使用する必要があります。 手書きの XML や署名処理は安全ではありません。

****** #

JWT はトークン形式であり、セッションプロトコルではありません。リソースサーバーは署名を 検証するか、信頼できるイントロスペクション結果を取得したうえで、issuer、audience、 有効期限、not-before 時刻、認可クレームを検証する必要があります。期限切れでない ベアラートークンを認証情報として扱い、短いアクセストークン有効期間、スコープベースの 認可、鍵のローテーション、アプリケーションのリスクプロファイルに応じた失効設計を 使用してください。

検証せずにトークンの内容を認可判断に使用しないでください。トークンを暗号化しても、 クレームを検証する必要はなくなりません。