4

OAuth2 仕様の実装を計画しており、「アクセス トークン」の実装を検討しています。仕様は実装者に多くの自由を与えているように見えます。私たちはいくつかのベストプラクティスを探しています:

  1. アクセストークンには何を入れる？サイズと実用性のバランスを取りたい。これは非常にアプリケーション固有のものであることは理解していますが、おそらく本当に価値のあるものがいくつかあります。

これまでのところ、次のフィールドを特定しました。

  • ユーザー識別子
  • 有効期限
  • バージョン (将来的にフォーマットを変更できるようにするため)
  • クライアント識別子 (つまり、トークンを要求したアプリ)

いくつかの追加の属性 (パスワード ハッシュなど) はデータベースに格納され、認証中に検索されます (トークンのフィールドを「キー」として使用)。

  1. それを確保する方法は？

アクセス トークン (HMAC) が改ざんされたかどうかを確認できるように、安全に署名する方向に傾いています。トークン内のフィールドは、誰でも読み取ることができます。

別の方法は、全体を暗号化 (AES) し、ユーザーに対して完全に不透明にすることです。これにより、(バイト単位で) はるかに大きくなります。FB は暗号化されたトークンを使用しているようです (http://developers.facebook.com/blog/post/572/)。

業界のベストプラクティスに関する提案はありますか?

ありがとう、ピョートル

4

1 に答える 1

1

発行したアクセス トークンを有効期限などとともにバックエンドのユーザーにマップできる限り、生成方法は問題ではありません (予測可能であってはならないことを除けば)。仕様は実装の詳細を示していません。

トークンは、バックエンドでユーザー状態にマップされた一意に生成された文字列にすることも、ユーザー情報や有効期限などをト​​ークン自体に暗号化することもできます。その場合は SWT を検討してください。SWT 形式は、記述内容を正確に定義します。これには、ユーザー、clientId、スコープなどに関するクリア テキストの情報が含まれていますが、改ざんを防止するために暗号化されたキーも提供されます。共有シークレットを使用すると、キーが別のサーバーまたは別のパーティで生成されたものであっても、キーを検証できます。それらはかなり大きくなる傾向があるため、クエリ文字列を渡すには理想的ではありません。

トークンを生成できるクラウドベースの STS ソリューションがあります。たとえば、Azure ACS は、OAuth2 エンドポイントを介して SWT トークンを生成し、更新トークン、有効期限、承認付与に関連するすべての状態を管理できます。これを使用することで節約できるものは、統合する方法を理解するのにおそらく失敗するでしょうが、それは非常に優れています.

于 2013-02-02T01:12:19.403 に答える