問題タブ [cookie-httponly]

web.config で httponlycookie が true になっているので、JavaScript でサーバー側の Cookie にアクセスして UI のブロックを解除することはできません。Cookie の値を使用せずに UI をブロックするオプションはありますか

UI コードのブロックとブロック解除:

最近、自分の Web サイトでセキュリティ監査を受け、「auth」Cookie に「HttpOnly」を適用する必要があると通知されました。

web.config ファイルでこれを変更する方法がわかりません。

サイトは ASP.NET MVC です。

誰かが私を正しい方向に向けることができれば幸いです。

注：この質問には4つの報奨金がありましたが、以下の支持された回答は、この質問に必要な回答ではありません. 必要なものはすべて以下の Update 3 にあり、実装する Laravel コードを探すだけです。

更新 3: このフローチャートはまさに私が達成しようとしているフローです。以下のすべては、いくつかの古い更新を含む元の質問です。このフローチャートは、必要なすべてをまとめたものです。

以下のフローチャートの緑色の部分は、私が実行方法を知っている部分です。赤い部分とそのサイド ノートは、Laravel コードを使用して達成するために私が探しているものです。

私は多くの調査を行いましたが、自己消費型 API 用の JWT httponly cookie を使用して Laravel を使用する場合、情報は常に短く、完全ではありません (オンラインのほとんどのチュートリアルでは、JWT がローカルストレージに保存されていることのみを示していますが、これはあまり安全ではありません) ）。Passport による JWT を含む httponly Cookie を使用して、サーバーへのすべての要求とと​​もに送信されたときに Javascript 側でユーザーを識別し、ユーザーが本人であることを検証する必要があるようです。

このセットアップを機能させる方法の全体像を把握するために必要ないくつかの追加事項もありますが、これをカバーする単一のチュートリアルでは見つけられませんでした。

1. 暗号化された JWT を生成し、JS 側からのログイン後にレスポンスとして httponly Cookie として送信する Laravel Passport (tymon auth ではない)。どのミドルウェアを使用しますか? リフレッシュ トークンによってセキュリティが強化される場合、実装方法は?
2. 認証エンドポイントを呼び出す JavaScript (axios など) API 疑似コ​​ード、httponly Cookie がバックエンドに渡される方法、およびバックエンドがトークンを検証する方法が有効です。
3. 単一のアカウントが複数のデバイスからログインしている場合、デバイスが盗まれます。認証されたすべてのユーザー デバイスからのアクセスを取り消す方法は?
4. ログイン/登録、ログアウト、パスワードの変更、パスワードを忘れた場合のコントローラー メソッドは、通常、トークンの作成/検証/取り消しを処理するためにどのように見えるでしょうか?
5. CSRF トークンの統合。

この質問への回答が、将来の読者や、自己消費 API に関する上記の点をカバーする回答を見つけるのに現在苦労している読者にとって、わかりやすいガイドとして役立つことを願っています。

更新 1:

1. 以前に試してみましたCreateFreshApiTokenが、ユーザーのトークンの取り消しに関してはうまくいきませんでした (上記のポイント 3 と 4 の場合)。これは、ミドルウェアについて話しているときのコア laravel 開発者による次のコメントに基づいています。CreateFreshApiToken

このミドルウェアによって作成された JWT トークンはどこにも保存されません。それらを取り消すことも、「存在しない」こともできません。これらは、laravel_token Cookie を介して API 呼び出しを認証する方法を提供するだけです。アクセストークンとは関係ありません。また、通常、トークンを発行するのと同じアプリでクライアントによって発行されたトークンを使用することはありません。ファースト パーティまたはサード パーティのアプリでそれらを使用します。ミドルウェアまたはクライアント発行トークンのいずれかを使用しますが、両方を同時に使用しないでください。

ということでポイント3と4のトークンの無効化には対応できそうですが、CreateFreshApiTokenミドルウェアだと無理です。

2. クライアント側でAuthorization: Bearer <token>は、セキュアな httpOnly Cookie を扱う場合、これは適切ではないようです。laravel docs に基づいた次のように、リクエスト/レスポンスにはセキュアな httpOnly Cookie をリクエスト/レスポンスヘッダーとして含める必要があると思います:

この認証方法を使用する場合、デフォルトの Laravel JavaScript スキャフォールディングは、X-CSRF-TOKEN および X-Requested-With ヘッダーを常に送信するように Axios に指示します。

これが、上記のすべてのポイントをカバーするソリューションを探している理由でもあります。申し訳ありませんが、5.5 ではなく Laravel 5.6 を使用しています。

更新 2:

Password Grant/Refresh Token Grantの組み合わせが最適なようです。Password Grant/Refresh Token Grantコンボを使用したわかりやすい実装ガイドを探しています。

パスワード グラント: このグラントは、当社の Web サイト用のモバイル アプリなど、信頼できるクライアントを扱う場合に適しています。この場合、クライアントはユーザーのログイン資格情報を認可サーバーに送信し、サーバーはアクセス トークンを直接発行します。

Refresh Token Grant: サーバーがアクセス トークンを発行すると、アクセス トークンの有効期限も設定されます。リフレッシュ トークン グラントは、有効期限が切れたアクセス トークンをリフレッシュする場合に使用します。この場合、認可サーバーはアクセス トークンの発行中に更新トークンを送信します。これを使用して、新しいアクセス トークンを要求できます。

上記の元の5つのポイントのすべての部分をhttpOnlyセキュアCookie、トークンの作成/取り消し/更新、ログインCookieの作成、ログアウト Cookie の取り消し、コントローラー メソッド、CSRF など。