OAuthトークンの生成に関するベストプラクティスは？

私がいることを実感OAuthの仕様は、特にトークン（ConsumerKey、ConsumerSecret、AccessToken、RequestToken、TokenSecret、または検証用コードの起源については何も指定しませんが、非常に安全なトークンを作成するための任意のベストプラクティスがある場合、私は好奇心が強いです/秘密の組み合わせ）。

私が見るように、トークンを作成するにはいくつかのアプローチがあります：

1. ランダムなバイトを使用し、コンシューマー/ユーザーに関連付けられたDBに保存します
2. 一部のユーザー/コンシューマー固有のデータをハッシュし、コンシューマー/ユーザーに関連付けられたDBに保存します
3. ユーザー/消費者固有のデータを暗号化する

（1）の利点は、データベースが最も安全と思われる唯一の情報源であることです。（2）や（3）よりも攻撃を行うのは難しいでしょう。

実際のデータ（2）をハッシュすると、おそらく既知のデータからトークンを再生成できます。とにかく保存/検索する必要があるので、（1）には実際には何の利点も提供しない可能性があります。（1）よりもCPUに負荷がかかります。

実際のデータを暗号化すると（3）、暗号化を解除して情報を知ることができます。これは、（1）と（2）よりも必要なストレージが少なく、検索数が少ない可能性がありますが、安全性も低くなる可能性があります。

考慮すべき他のアプローチ/利点/欠点はありますか？

編集：別の考慮事項は、トークンに何らかのランダムな値が存在する必要があることです。これは、新しいトークンを期限切れにして再発行する機能が存在する必要があるため、実際のデータのみで構成されてはならないためです。

続く質問：

暗号的に非常に安全にするための最小トークン長はありますか？私が理解しているように、トークンシークレットが長いほど、より安全な署名が作成されます。この理解は正しいですか？

ハッシュの観点から、特定のエンコーディングを別のエンコーディングよりも使用する利点はありますか？たとえば、16進エンコーディング（GUID文字列など）を使用する多くのAPIが表示されます。OAuth署名アルゴリズムでは、トークンは文字列として使用されます。16進文字列を使用すると、Base64エンコーディングを使用する場合よりも、使用可能な文字セットがはるかに小さくなります（予測可能になります）。同じ長さの2つの文字列の場合、文字セットが大きい文字列ほど、ハッシュ分布が広くなります。これにより、セキュリティが向上すると思われます。この仮定は正しいですか？

OAuth仕様では、この問題が11.10 Entropy of Secretsで発生しています。

OAuthは、秘密が関連付けられていることを除いて、トークンについては何も述べていません。したがって、あなたが言及したすべてのスキームが機能します。私たちのトークンは、サイトが大きくなるにつれて進化しました。以前使用したバージョンは次のとおりです。

1. 最初のトークンは、ユーザー名、トークンシークレット、有効期限などが暗号化されたBLOBです。問題は、ホストにレコードがないとトークンを取り消せないことです。

2. そのため、すべてをデータベースに格納するように変更しました。トークンは、データベースへのキーとして使用される単なる乱数です。ユーザー名のインデックスがあるので、ユーザーのすべてのトークンを一覧表示して取り消すのは簡単です。

3. ハッキング活動はほとんどありません。乱数では、トークンが有効かどうかを知るためにデータベースにアクセスする必要があります。そこで、再び暗号化されたBLOBに戻りました。今回は、トークンには暗号化されたキーの値と有効期限のみが含まれます。したがって、データベースにアクセスすることなく、無効なトークンや期限切れのトークンを検出できます。

あなたを助けるかもしれないいくつかの実装の詳細、

1. トークンにバージョンを追加して、既存のバージョンを壊すことなくトークンの形式を変更できるようにします。すべてのトークンの最初のバイトはバージョンです。
2. Base64のURLセーフバージョンを使用してBLOBをエンコードします。これにより、URLエンコードの問題に対処する必要がなくなります。これにより、トリプルエンコードされたベース文字列が表示される可能性があるため、OAuth署名でのデバッグが困難になります。