アクセストークンと更新トークンを使用したトークンベースの認証

存続期間の短いアクセストークンと存続期間の長いリフレッシュトークンを使用して、REST APIのトークンベースの認証システムを実装しています。これは、関連するAPIエンドポイントの抽象的な概要です（HTTPSはすべてのエンドポイントに適用されます）。

エンドポイント：

POST /register/
POST /login/
POST /logout/
POST /password/change/

実装：

POST /register/：

• リクエスト：クライアントがユーザー名、メール、パスワードをJSONで送信します。
• サーバーアクション：
  1. 入力を検証し、データベースにユーザーを作成します（ユーザーID、ユーザー名、電子メール、パスワードハッシュを格納します）。
  2. JWT形式で短期間有効なアクセストークンを作成します（ユーザーID、発行日、有効期限が含まれます）。
  3. 長期間有効な更新トークンをUUID文字列として作成し、データベースに保存します（ユーザーIDと更新トークンを保存します）。
• 応答：サーバーはJSONでアクセストークンと更新トークンを返します。

POST /login/：

• リクエスト：クライアントはJSONでユーザー名とパスワードを送信します。
• サーバーアクション：
  1. 入力を検証し、データベースをチェックして資格情報が有効かどうかをチェックします。
  2. 資格情報が有効な場合、前述のように、有効期間が短いアクセストークンと有効期間が長いリフレッシュトークンを作成します。
• レスポンス：と同じで/register/、アクセストークンと更新トークンをJSONで返します。

POST /logout/：

• 要求：クライアントはヘッダー内の更新トークンをトークンAuthorizationとして送信しBearerます。
• サーバーアクション：
  1. 更新トークンデータベースをチェックして、更新トークンを検証します。
  2. データベースから更新トークンを削除します。
     注：これにより、アクセストークンは有効なままになりますが、有効期間は短いため（1時間程度なので、問題ないはずです）。
• 応答：ログアウト要求がJSONで正常に処理されたかどうかを返します。

POST /password/change/：

• リクエスト：クライアントはアクセストークンをAuthorizationヘッダーとしてBearerトークンとして送信し、古いパスワードと新しいパスワードをHTTPS経由でJSONで送信します。
• サーバーアクション：
  1. アクセストークンをデコードしてユーザーを取得し、ユーザーの古いパスワードをデータベースで確認します。
  2. データベース内のユーザーのパスワードハッシュを新しいパスワードのハッシュに設定します。
  3. リフレッシュトークンデータベース内のユーザーに関連付けられたすべてのリフレッシュトークンを削除して、基本的に既存のセッションをログアウトします（有効期間の短いアクセストークンを残します）。
• 応答：パスワード変更リクエストがJSONで正常に処理されたかどうかを返します。

質問：

1. このアプローチは安全ですか？具体的には：
   • HTTPSを介して行われる場合、JSONを介したユーザー名とパスワードの送信は安全ですか？無許可のドメインがこのエンドポイントに電話をかけることをどのように防ぐことができますか？さらに、プログラムによるログインを防ぐにはどうすればよいですか？
   • 更新トークンをデータベースに保存する前にハッシュ化する必要がありますか、それとも単なる偏執狂ですか？
2. クライアントがWebブラウザーの場合、更新トークンをクライアントに安全に保存するにはどうすればよいですか？
   • リフレッシュトークンを保存するための1つのアイデアは、ユーザーがログインすると、リフレッシュトークンをクライアントに送信するだけでなく、サーバーがトークンをフラグHttpOnly付きのCookieに保存することsecureです。承認は引き続きAuthorizationヘッダーを介して行われますが、クライアントが最初に読み込まれるときにGET、Cookieに有効な更新トークンが含まれているかどうかを確認するリクエストをエンドポイントに送信でき、有効な更新トークンが含まれている場合はJSONでユーザーに返します。つまり、Cookieが実際に使用されるのは、Cookie内の更新トークンをクライアントに返すときだけです。このアプローチは安全ですか？Cookieからリフレッシュトークンを要求するときに副作用がないため、CSRFを防ぐことができると思いますが、攻撃者がリフレッシュトークンを傍受する別の方法があります（HTTPSを想定）？

このアプローチは安全ですか？具体的には：

• HTTPSを介して行われる場合、JSONを介したユーザー名とパスワードの送信は安全ですか？

はい。ヘッダー、要求パラメーター、および要求本文は、通信中に暗号化されます。

サーバー側では、リクエストの本文をログに記録しないでください:-)

• 無許可のドメインがこのエンドポイントに電話をかけることをどのように防ぐことができますか？

それはいけません。基本的に、APIがWWWに公開されると、あらゆる種類の悪意に自動的にさらされます。あなたができる最善のことは、準備をして脅威を認識することです。少なくともあなたに関係するものについて。見てくださいここに。

この問題への可能なアプローチは、API Managerを実装（または契約）することです。

AMの背後にあるすべてのエンドポイントが必ずしもパブリックであるとは限らないため、オンプレミスAPIマネージャーは攻撃対象を減らすことができます。

クラウド内の一部の製品で同じ結果を得ることができますが、それらは主流にとっては驚くほど高価です。

とにかく、API管理エンドポイントは攻撃にさらされたままになります。

• さらに、プログラムによるログインを防ぐにはどうすればよいですか？

プログラムによるログインとは、ブルートフォースによる攻撃を意味する場合、しきい値（1秒あたりの許可されるリクエストの最大数）とブラックリストで攻撃者の主張を阻止できます。詳細については、こちらをご覧ください。

API Managerの多くは、すぐに使用できるAPIレート制限構成とホワイトリストを提供します。

Google API Consoleに精通している場合は、API Managerが何を実行できるかを推測できます。

• 更新トークンをデータベースに保存する前にハッシュ化する必要がありますか、それとも単なる偏執狂ですか？

更新トークンがプレーンなUUIDであろうとなにであろうと、この種の実装の詳細を公開したくありません。だから私はそれをハッシュ化することをお勧めします。私にとっては、セキュリティ層の実装の詳細が不透明であるほど良いでしょう。

JWTのセキュリティについては、こちらをご覧ください。

• クライアントがWebブラウザーの場合、更新トークンをクライアントに安全に保存するにはどうすればよいですか？

JSON Web Token（JWT）-クライアント側のストレージに興味があるかもしれません。