0

なぜクライアント シークレットが必要なのですか?

これは論理的ではありません。REST呼び出しを直接行うときにシークレットが必要な理由を誰かに説明してもらえますか?

JavaScript API は「クライアント シークレット」を必要としません。

WL.init({
    client_id: APP_CLIENT_ID,
    redirect_uri: REDIRECT_URL,
    scope: "wl.signin", 
    response_type: "token"
});

ただし、REST 呼び出しを直接行いたい場合は、次のものが必要です。

POST https://login.live.com/oauth20_token.srf

Content-type: application/x-www-form-urlencoded

client_id=CLIENT_ID&redirect_uri=REDIRECT_URL&client_secret=CLIENT_SECRET&code=AUTHORIZATION_CODE&grant_type=authorization_code

コード: http://msdn.microsoft.com/en-us/library/hh243641.aspx

クライアントシークレットはセキュリティ機能であると想定していますが、そうであれば、js API を介した接続は、サービスへの直接接続よりも少ないセキュリティ制約で作成できるのはなぜですか? そのため、コンテキストによっては「オプションで必要」のように見えますが、それは矛盾した表現ですが、何かを見逃している可能性があります。

4

1 に答える 1

0

おそらく、サーバー側のコードにより、次のようなより多くのアクセスが提供されるためです。

必須。サインインしているユーザーが同意するスコープを指定します。スコープが 1 つの場合は、次の形式を使用します: scope: "wl.signin"。複数のスコープの場合は、次の形式を使用します: scope: ["wl.signin", "wl.basic"]。スコープが指定されていない場合は、WL.init のスコープ値が使用されます。WL.init または WL.login にスコープが指定されていない場合、WL.login はエラーを返します。注 WL.login は「wl.offline_access」スコープを要求できますが、サーバー側の実装が必要であり、WL.init 関数はその response_type プロパティを「code」に設定する必要があります。

基本的に、クライアント シークレットを使用すると、より高いセキュリティ クリアランスが得られるため、他の方法ではできない追加の情報にアクセスできます。

注: ライブ SDK ダッシュボードでアプリをデスクトップ/モバイル アプリとしてプロビジョニングすることで、この制限を回避できる場合があります。

于 2014-10-19T06:59:20.123 に答える