9

DotNetOpenAuth に基づいて OAuth2 承認/リソース サーバーを実装しています。私のサーバーは、非常に長い有効期間を持つアクセス トークンを発行します。これらのトークンは、iOS デバイスから使用されます。私の見方では、フローは次のようになります。1) ユーザーは iOS デバイスでユーザー名/パスワードを入力するように求められます 2) リソース所有者パスワード資格情報の付与タイプでアクセストークンが要求されます 3) トークンが付与され、保存されます将来の使用のために iOS デバイスで。

時々、ユーザーが無効になります。同時にトークンを取り消したいと思います。どうすればいいですか？そのためにメソッドを使用する必要があると思わICryptoKeyStore.RemoveKeyれますが、削除するキーを見つける方法がわかりません。

注 1: 将来、サーバーはサードパーティの Web アプリケーションによって使用されます。

注 2: Resource Owner Password クレデンシャルのグラント タイプが必要な理由は、iOS デバイスにブラウザ リダイレクトを実装する価値がないと判断されたためです。

更新 1 ソース コードの一部の発掘調査では、DotNetOpenAuth は、そのままではトークンの有効期限を強制するこの機能をサポートしていないことが示唆されています。さらに、標準実装では、トークンの有効期間はチェックさえされません。私が見ることができる限り、これは calss が原因であり、プロパティとプロパティをStandardAccessTokenAnalyzer無視します。また、標準クラスにはデータベース アクセスがコード化されていないようで、トークンの有効性はトークン コンテンツによってのみチェックされるため、トークンを期限切れにする機能を追加する必要がある場合は、自分でデータベースに接続する必要があるようです。何か不足していますか？LifetimeUtcCreationDateResourceServerResourseServer

更新 2 ここで答えを見つけたと思います: https://groups.google.com/forum/#!topic/dotnetopenid/aLabu1ujkt4これは私が望んでいたものではなく、まだ不明な点がいくつかあります。たとえば、アンドリューは次のように書いています。

その後、カスタム クラスはアクセス トークンを受け取り、承認サーバーへのプライベート HTTP 要求を使用して、トークンの継続的な有効性を検証します。

認証 ID が含まれていないため、この検証がどのように行われるかは不明です。AccessTokenこれにより、ターゲットの Authorization レコードを見つけるのが難しくなる可能性があります。理論的には、クライアント、ユーザー、および発行時間の組み合わせで検索を試みることができますが、私が見る限り、これらが一意であるという保証はありません。

4

1 に答える 1

8

時々、ユーザーが無効になります。同時にトークンを取り消したいと思います。どうすればいいですか？そのために ICryptoKeyStore.RemoveKey メソッドを使用する必要があると思われますが、削除するキーを見つける方法がわかりません。

トークンの背後にある承認を取り消すことで、トークンを取り消します。これは通常、データベースの権限テーブルのエントリを削除することを意味します。これが持つ必要がある効果は、 の実装がIAuthorizationServerHost.IsAuthorizationValidこの承認に対して false を返すことです。

これにより、アクセス トークンがすぐに取り消されるわけではありませんが、クライアントが期限切れのアクセス トークンを更新するのをブロックします。したがって、アクセス トークンの有効期間がかなり短い (1 時間以下) 場合、ユーザーの無効なアカウントは、すべてのクライアント アクセスが 1 時間以内に終了することを意味します。

注 2: Resource Owner Password クレデンシャルのグラント タイプが必要な理由は、iOS デバイスにブラウザ リダイレクトを実装する価値がないと判断されたためです。

それはあなたのアプリです。しかし、すべての人に適切なブラウザ リダイレクト フローを使用することをお勧めします。ユーザーは、デバイスのブラウザーでサーバーに既にログインしている可能性が高いため、この方法で資格情報を入力することを完全に回避できるため、コンバージョン率が向上します。また、ユーザーは、デバイス アプリよりも、資格情報を要求するブラウザーを信頼する可能性が高くなります。少なくともそう願っています。

ところで、リソース所有者のパスワード付与タイプは、通常、インストールされたデバイス アプリがサポートする非認証クライアント (TBD) ではサポートされない可能性があります。そのため、別の許可タイプを使用せざるを得なくなる場合があります。

更新 1ソース コードの一部の発掘調査では、DotNetOpenAuth は、そのままではトークンの有効期限を強制するこの機能をサポートしていないことが示唆されています。さらに、標準実装では、トークンの有効期間はチェックされません。私が見る限り、calss がこれを担当しており、これは StandardAccessTokenAnalyzer であり、Lifetime および UtcCreationDate プロパティを無視します。

DotNetOpenAuthは、期限切れのアクセス トークンをチェックして拒否します。そのクラスにいないだけです。アクセス トークンを逆シリアル化するコードでチェックされます。

また、標準の ResourceServer クラスにはデータベース アクセスがコード化されていないようで、トークンの有効性はトークンの内容によってのみチェックされるため、トークンを期限切れにする機能を追加する必要がある場合は、ResourseServer を自分でデータベースに接続する必要があるようです。 . 何か不足していますか？

ResourceServerアクセス トークンは有効期間全体にわたって有効であると想定されるため (デフォルトでは取り消し不可) 、クラスがデータベース アクセスを必要としないことは正しいことです。これが、短いアクセス トークンの有効期間が推奨される理由です。これは、あなたが思っているほど遠いものではありません。たとえば、すでに使用されている可能性が非常に高い ASP.NET フォーム認証は、同じパターンに基づいています。ユーザーを一度認証し、資格情報チェックのためにデータベースにアクセスしてから、暗号化および署名された HTTP Cookie をユーザー エージェントに発行します。その時点から、データベースはすべての着信 HTTP 要求でヒットするわけではありません。Cookie の署名が検証され、Cookie の有効期限が切れるまで有効であると見なされます。同じ原理。ただし、HTTP cookie の場合は、スライディングがあります。ユーザーがサイトでアクティブなままである限り、再認証する必要がないようにします。OAuth 2 アクセス トークンを使用すると、使用頻度に関係なく有効期限が切れ、トークンの更新が強制されます。トークンの更新を拒否すると、アクセスがロックアウトされます。

AccessToken に Authorization Id が含まれていないため、この検証がどのように行われるかは不明です。これにより、ターゲットの Authorization レコードを見つけるのが難しくなる可能性があります。理論的には、クライアント、ユーザー、および発行時間の組み合わせで検索を試みることができますが、私が見る限り、これらが一意であるという保証はありません。

ID が含まれていないのは事実ですが、client-user-issuedate-scope のタプルは一意である必要があります。これは、重複があると意味がないため、承認テーブルに一意の制約を設定する必要があるためです。さらに、それらが一意でない場合、そのタプルを持つレコードが存在するだけで、承認が有効であることが示唆されます。

お役に立てれば。

于 2012-05-02T00:15:27.763 に答える