要するに、違います。 Mongo ObjectIds 推測しやすいです。特に、高負荷では、タイムスタンプ、マシン、およびプロセスIDが変更されないため、これらは連続した番号であることがよくあります。 Objectidの構造
を見ると 、それらはで構成されています
a 4-byte timestamp,
a 3-byte machine identifier,
a 2-byte process id, and
a 3-byte counter, starting with a random value.
したがって、ランダム性はほとんどありません。たとえば、コントローラーのアクションによってドメインオブジェクトが書き込まれ、ログエントリがすばやく連続して書き込まれる場合など、データベースに連続したIDが表示されることがよくあります。
タイムスタンプを推測でき、マシンIDを判別できる場合（巨大なクラスターがない限り）、残りは5バイトだけです。生成されたIDの数を調べることで、おそらくそれを50プロセス程度に減らすことができるので、有効なエントロピーは28ビット範囲のどこかにあります。これはまだ推測が難しいですが、アクセストークンにはリスクが高すぎます。
代わりに、暗号的に強力な疑似乱数ジェネレーターを使用して、そこからトークンを作成します。たとえば、.NETでは、RNGCryptoServiceProvider 任意の長さのランダムデータを作成できます。
補足として、2つの理由から、OAuthTokenの周りに追加の暗号ラッパーを用意することをお勧めします。
a）無効なトークンをすばやく特定できるようにする必要があります。有効な暗号化シェルには、無効なトークン（失効または期限切れの許可）が含まれている可能性がありますが、毎回ブルートフォース攻撃でデータベースを攻撃する必要はありません。また、クライアント
b）クライアントはトークンを何度も要求できます。これは必須ではありませんが、私が知っているほとんどすべてのシステムは、毎回異なるトークンを返します（自己検証であるかどうかは関係ありません）。通常、これはトークン自体の有効期間が限られているためです。これは、OAuth付与と同じ有効期間ではありません。
データベースに実際に保存したいのは、付与、つまり、あるユーザーからあるクライアントに与えられた権限です。この付与が削除されると、すべてのトークンが無効になります。アプリケーションの許可を効果的に削除するには、ユーザーがすべてのトークンを削除する必要があるため、毎回新しいトークンを挿入するのは非常に便利です。