API desing - 認証トークンからユーザーのデータを取得できますか？

Question

のは、このユースケースを考えてみましょう：

1）私は、ユーザー名とパスワードを使用して、私のAPIのログインエンドポイントを呼び出すと、私はAuthorization: Bearer <token>としてヘッダにすべての連続した要求に追加私の認証トークンを取得します。

2）私は/current-userエンドポイントをパラメータなしで呼び出し、認証ヘッダーのみを呼び出します。サーバーはトークンを使用するユーザーを認可し、そのトークンからユーザーのIDを取得します。次に、彼はデータベース内のidによってユーザを見つけ、そのデータを返します。

私の質問は、このアプローチが安全でないかどうかです。私は攻撃者で無作為に生成されたトークンを使用して/current-userエンドポイントに電話していた場合はどうですか？時々私が実際のトークンと一致すると、サーバーは他のユーザーのデータを返します。

トークンとコールの両方のリクエストを使用してクライアントにユーザIDを格納する必要はありませんか？例えば。承認ヘッダーのある/user?id=<stored user id>を削除し、/current-userエンドポイントを削除しますか？その後、使用されたトークンが、渡されたユーザーIDを持つユーザーへのアクセスを許可しているかどうかを、サーバー上のACLの種類によって判断します。セキュリティ上の目的のために

（私も、私は何とか他のユーザーのトークンとサーバを推測するために管理します攻撃者が私に彼のデータが返されるように。そこJWTトークンはあるが、私はそこに同じ問題を見た）

Answer 1

、それがありますとにかくユーザーIDが攻撃者に知られていると通常想定しています。たとえば、攻撃者が既に正当なアカウントを持っているか知っている場合、他のユーザーIDがどのように割り当てられているかを推測することができます。

また、トークンが十分長く、完全にランダムであれば、実際には違いはありません。

このように見てください。トークンの長さがnで、ユーザーIDの長さがmであるとします。ユーザーIDがなければ、攻撃者はn文字を推測しなければならず、それにはn+m文字を推測する必要があります。 nが十分に高い場合は、余分な文字は必要ありません。ユーザーIDが完全にランダムでない場合、有効なのユーザーIDの長さは、見かけの長さよりもかなり短くなる可能性があるので、実際には実際には非常に小さいかもしれません。

Answer 2

デジタル署名付きトークンを使用することは可能ですか？基本的には、クライアント（またはユーザー）の秘密鍵でトークンを暗号化してから、サーバーの公開鍵で平文のユーザーIDとともにパッケージを暗号化することができます。そうすれば、サーバーだけがパッケージを解読し、解読すると、そのユーザーは誰であるかが分かります。次に、そのユーザーIDに関連付けられた公開鍵を使用して、パッケージを解読してトークンを取得することができます。

アプリケーションに関する多くの情報と、必要な認証の速度や、使用しているテクノロジーがないので、これ以上の情報を提供することは困難です。