1

私は現在、iPadアプリケーションが既存のWebアプリケーションへのアクセスを必要とするプロジェクトに取り組んでいます。iPadアプリケーションは社内で開発されているため、信頼できるアプリケーションです。ただし、Webアプリケーションによって提供されるデータは機密性が高いため、クライアントの資格情報をiPadに保存する必要はありません。また、通常のユーザーアクセスに影響を与えることなくiPadアクセスを取り消す機能も必要です。

上記のことを考えると、OAuth2リソース所有者のパスワードクレデンシャルの付与/フローは、確立されたライブラリ以来、DotNetOpenAuthで実装した要件にぴったりでした。

ただし、リソースサーバーのアクセストークンと更新トークンにメタデータを追加する必要があります。承認サーバーは、IAuthorizationServerHost.CreateAccessTokenメソッドの実装でAuthorizationServerAccessToken.ExtraDataプロパティを介してメタデータを追加しています。

public AccessTokenResult CreateAccessToken(IAccessTokenRequest accessTokenRequestMessage)
{
    var accessToken = new AuthorizationServerAccessToken();

    // Add some extra data to access token
    accessToken.ExtraData.Add("server_parameter1", this.ServerValue1);
    accessToken.ExtraData.Add("server_parameter2", this.ServerValue2);

    // Set ResourceServerEncryptionKey properties etc

    return new AccessTokenResult(accessToken);
}

これはアクセストークンに必要なことを正確に実行しますが、同じ「ExtraData」が更新トークンに含まれていないため、アクセストークンの有効期限が切れたときに問題が発生し、追加のデータが事実上失われるため、更新する必要があります（古いアクセストークン以降）破棄されます）。

アクセストークンと同様の方法で、現在のバージョンのDotNetOpenAuthに更新トークン「ExtraData」を入力できるかどうかを誰かにアドバイスできますか？

4

1 に答える 1

1

いいえ、現在、更新トークンに追加のデータを埋め込む方法はないと思います。これがなぜであるかについて少し話しましょう。

まず第一に、あなたがそれを開発するかどうかにかかわらず、信頼できるiPadアプリのようなものはありません。問題は、配布するアプリが（内部的にも）秘密を保持できないことです。client_secret、証明書などはすべて解読される可能性があります。したがって、配布するアプリはサーバーに対して自分自身を認証できません。サーバーがクライアントを認証できない場合、サーバーはクライアントを信頼できません。

次に、シナリオをもう少し見てみましょう（さらにフィードバックがある場合は、dotnetopenid @ googlegroups.comでディスカッションを続けるのが最善の場合があります）。クライアントには、最終的にリソースサーバーに到達したいデータがあります。現在、最初に認証サーバーを介して、次にアクセストークンを介してリソースサーバーにそのデータを渡そうとしています。何故ですか？クライアントにアクセストークンと一緒にデータをリソースサーバーに直接送信させないのはなぜですか？答えがリソースサーバーがクライアントを信頼してはならないということである場合、アクセストークンを介してクライアントを送信することによって得られるものは、上記の段落で示した理由により、誤った安心感です。クライアントがリソースサーバーに誤った情報を提供する可能性がある場合、承認サーバーにも誤ったデータを提供する可能性があります。

アクセストークンでの追加データの有効な使用法の1つは、認証サーバーが自身で認識しているデータであり、クライアントからのデータではありません。この場合、アクセストークンが作成されるたびにそのデータを検索できるため、更新トークンに保存する必要はありません。

于 2012-10-18T15:31:26.080 に答える