ホームページ >バックエンド開発 >PHPチュートリアル >Oauth2.0 の開発 ユーザーを識別するために、ユーザーが access_token を送信したり、その他の 1 つまたは 2 つの固定パラメーターを使用したりする必要があるのはなぜですか?

Oauth2.0 の開発 ユーザーを識別するために、ユーザーが access_token を送信したり、その他の 1 つまたは 2 つの固定パラメーターを使用したりする必要があるのはなぜですか?

WBOY
WBOYオリジナル
2016-06-23 13:33:40776ブラウズ

最近、APP リクエストの検証インターフェイス (クライアント側ではなくサーバー側) を開発したいと考えています。Oauth プロトコル プロセスを通じて access_token を取得した後、次の操作 (追加、削除、変更、ユーザーの身元を確認し、追加、削除、変更、確認操作を実行するには、access_token、または OpenID と APPKey (これらのパラメーターの有効期間は比較的長く、通常は数日です) を送信する必要があるだけです。理解できませんが、これらのパラメータが漏洩した場合、または盗まれた場合、他の人(サードパーティ)はこれらのパラメータを送信することでユーザーデータを変更できませんか?似たような開発をするのは初めてなので、アドバイスをお願いします。ソースコードも教えていただければ幸いです。サーバー側のやり取りが盗まれた場合、サーバーは安全ではなくなりますが、暗号化された openid は誰にとっても意味がありません。

これらの固有のパラメーターによってユーザーの ID が特定される理由がわかりません。サードパーティが使用できるインターフェイスを開発したいのですが、この手順が理解できません。実装してください

これらはすべてサーバー側で発生するやり取りです。盗まれた場合、サーバーは安全ではなくなりますが、暗号化された openid は誰にとっても意味がありません。

これらの固有のパラメーターを通じてユーザー ID が特定される理由がわかりません。サードパーティが使用するインターフェイスを開発したいのですが、この手順を理解できません。解決してください。

openid はユーザーの唯一の認証情報であり、ユーザーのすべてのデータに関連付けられています。バックグラウンドで実装するにはどうすればよいですか?バックステージの誰のことを言っているのですか?ユーザーがプラットフォームでプレイするとき、プラットフォームはユーザーの情報とユーザーのニーズを取得できる必要があり、プラットフォームはユーザーの情報とニーズに基づいてフィードバックを提供することもできます。インターフェースをサードパーティに提供するかどうかを決定するには?

openid はユーザーの唯一の認証情報であり、ユーザーのすべてのデータに関連付けられています。バックグラウンドでどのように実装されますか?バックステージの誰のことを言っているのですか?ユーザーがプラットフォームでプレイするとき、プラットフォームはユーザーの情報とユーザーのニーズを取得できる必要があり、プラットフォームはユーザーの情報とニーズに基づいてフィードバックを提供することもできます。インターフェースをサードパーティに提供するかどうかを決定するには?


あなたは私の意味が理解できませんでした。おそらく私が明確に説明しなかったのでしょう。サードパーティがユーザーのアクセス トークン [access_token]、[OpenID]、およびサードパーティが取得した ID 識別子 [APPKey] を取得したと仮定します。アプリケーションに適用されると、サードパーティは HTTP リクエストを通じてこれら 3 つのパラメータを Tencent API インターフェイスに送信し、Tencent バックグラウンド プログラムはこれら 3 つのパラメータを判断することでユーザーの身元を確認し、現在の追加、削除、変更、およびクエリ操作を許可します。 Tencent バックエンド プログラムは OpenID を通じて対応するユーザーを見つけることができます。これは正しいです。私が理解できないのは、Tencent のバックグラウンド プログラムが現在の操作の合法性をどのように検証するか (現在のユーザーによって操作されていることを確認する) です。これら 3 つのパラメーターは (有効期間内で) 固定されているためです。たとえば、次のようになります。 (HTTP監視。..) Bが送信した3つのパラメータ情報を取得した後、Aは、これら3つのパラメータを送信することで、BがTencentサーバーに保存した情報にアクセスし、変更できることを意味するのではないでしょうか? Tencent のバックエンドがどのように検証するのか知りたくないのですが、検証のアイデアが欲しいだけです。

openid はユーザーの唯一の認証情報であり、ユーザーのすべてのデータに関連付けられています。バックグラウンドでどのように実装されますか?バックステージの誰のことを言っているのですか?ユーザーがプラットフォームでプレイするとき、プラットフォームはユーザーの情報とユーザーのニーズを取得できる必要があり、プラットフォームはユーザーの情報とニーズに基づいてフィードバックを提供することもできます。インターフェースをサードパーティに提供するかどうかを決定するには?

あなたは私の意味が理解できませんでした。おそらく私が明確に説明しなかったのでしょう。サードパーティがユーザーのアクセス トークン [access_token]、[OpenID]、およびサードパーティが取得した ID 識別子 [APPKey] を取得したと仮定します。アプリケーションに適用された場合、サードパーティは HTTP リクエストを通じてこれら 3 つのパラメータを Tencent API インターフェイスに送信し、Tencent バックグラウンド プログラムはこれら 3 つのパラメータを判断することでユーザーの身元を確認し、現在の追加、削除、変更、クエリ操作を許可します。 Tencent バックエンド プログラムは OpenID を通じて対応するユーザーを見つけることができます。これは正しいです。私が理解できないのは、Tencent のバックグラウンド プログラムが現在の操作の合法性をどのように検証するか (現在のユーザーによって操作されていることを確認する) です。これら 3 つのパラメーターは (有効期間内で) 固定されているためです。たとえば、次のようになります。 (HTTP監視。..) Bが送信した3つのパラメータ情報を取得した後、Aは、これら3つのパラメータを送信することで、BがTencentサーバーに保存した情報にアクセスし、変更できることを意味するのではないでしょうか? Tencent のバックエンドがどのように検証するのか知りたくないのですが、検証のアイデアが欲しいだけです。


ユーザーが oauth を通じてサードパーティを承認し、サードパーティが access_token を取得すると、プラットフォームはユーザーと直接の関係を持ちません。残りの操作は、サーバーが access_token の権限を通じてプラットフォームと対話することです。 access_token が漏洩した場合、サードパーティのサーバーが安全ではなくなったことを意味します。プラットフォーム上で実行できる検証は、この操作リクエストが access_token によって付与されたサードパーティ アプリケーションによって発行されたことのみを確認できます。この検証は、アプリケーションのドメイン名、IP、およびコールバック アドレスをバインドすることによって実現できます

このメソッドは、操作がユーザー自身によって発行されたかどうかを決定します。access_token が付与されている限り、ユーザーはそれ以上の操作を実行する必要はありません。そのため、access_tokenを第三者に付与する際には、第三者が認可後にどのような操作ができるかをユーザーが理解できるように、第三者が要求する権限をすべてユーザーに表示する必要があります

セキュリティ上の問題は存在しますが、実際、それらは大したことではありません
1. 情報がユーザーによって漏洩された場合、実際には、ユーザーはすでに危険にさらされています。ハッカーはこれら 3 つの値を取得する必要はまったくなく、ユーザーのユーザー名とパスワードを完全に盗み (多くの Web サイトは平文で送信します)、各 Web サイト上のユーザーのデータを直接変更できます。このようなことが起こった場合、ユーザーは自分が不運であることを認めることしかできず、あなたを責めることはありません。脆弱性が修正されると、ユーザーは安全にパスワードを変更できるようになります。
2. Tencent が提供する 3 つの値は、アプリケーションがインターフェイスで許可されているすべてのことを実行できることを意味します。つまり、実際には、Tencent がアプリケーションに公開するインターフェイスは、主に情報を取得するためのインターフェイスであり、一部はインタラクティブです。インターフェイス、および毎日のインタラクションの数も制限されます。 QQ パスワードを変更できますか? QQ ニックネームを変更できますか?個人情報は変更できません。これはどれも変更できませんし、ハッカーができることは何もないので、問題ありません。
3. サーバーが大規模なユーザーデータ漏洩を引き起こした場合は、運が悪かったと考えてください。バグを修正するにはサービスを停止する必要があります。変更が完了したら、AppKey を再生成して、補償メカニズムか何かを作成するのが安全です。

つまり、それでも許容されます。このメカニズムに問題があったとしても、テンセントはとっくの昔に別の方法を見つけていたでしょうし、あなたが心配する番ではありません。



openid はユーザーの唯一の認証情報であり、ユーザーのすべてのデータに関連付けられています。バックグラウンドでどのように実装されますか?バックステージの誰のことを言っているのですか?ユーザーがプラットフォームでプレイするとき、プラットフォームはユーザーの情報とユーザーのニーズを取得できる必要があり、プラットフォームはユーザーの情報とニーズに基づいてフィードバックを提供することもできます。インターフェースをサードパーティに提供するかどうかを決定するには?


あなたは私の意味が理解できませんでした。おそらく私が明確に説明しなかったのでしょう。サードパーティがユーザーのアクセス トークン [access_token]、[OpenID]、およびサードパーティが取得した ID 識別子 [APPKey] を取得したと仮定します。アプリケーションに適用された場合、サードパーティは HTTP リクエストを通じてこれら 3 つのパラメータを Tencent API インターフェイスに送信し、Tencent バックグラウンド プログラムはこれら 3 つのパラメータを判断することでユーザーの身元を確認し、現在の追加、削除、変更、クエリ操作を許可します。
Tencent バックエンド プログラムは OpenID を通じて対応するユーザーを見つけることができます。これは正しいです。私が理解できないのは、Tencent のバックグラウンド プログラムが現在の操作の合法性をどのように検証するか (現在のユーザーによって操作されていることを確認する) です。これら 3 つのパラメーターは (有効期間内で) 固定されているためです。たとえば、次のようになります。 (HTTP監視。..) Bが送信した3つのパラメータ情報を取得した後、Aは、これら3つのパラメータを送信することで、BがTencentサーバーに保存した情報にアクセスし、変更できることを意味するのではないでしょうか? Tencent のバックエンドがどのように検証するのか知りたくないのですが、検証のアイデアが欲しいだけです。
ユーザーが oauth を通じてサードパーティを承認し、サードパーティが access_token を取得すると、プラットフォームはユーザーと直接の関係を持ちません。残りの操作は、サーバーが access_token の権限を通じてプラットフォームと対話することです。 access_token が漏洩した場合、サードパーティのサーバーが安全ではなくなったことを意味します。プラットフォーム上で実行できる検証では、この操作リクエストが access_token によって付与されたサードパーティ アプリケーションによって発行されたことのみを確認できます。この検証は、アプリケーションのドメイン名、IP、コールバック アドレスをバインドすることによって実現できます
さて。 、ありがとう

確かにセキュリティ上の問題はありますが、実際には大きな問題ではありません
1. ユーザーの情報が漏洩すると、ユーザーは実際に危険にさらされます。ハッカーはこれら 3 つの値を取得する必要はまったくなく、ユーザーのユーザー名とパスワードを完全に盗み (多くの Web サイトは平文で送信します)、各 Web サイト上のユーザーのデータを直接変更できます。このようなことが起こった場合、ユーザーは自分が不運であることを認めることしかできず、あなたを責めることはありません。脆弱性が修正されると、ユーザーは安全にパスワードを変更できるようになります。
2. Tencent が提供する 3 つの値は、アプリケーションがインターフェイスで許可されているすべてのことを実行できることを意味します。したがって、実際には、Tencent がアプリケーションに公開するインターフェイスは、主に情報を取得するためのインターフェイスであり、一部はインタラクティブです。インターフェイス、および毎日のインタラクションの数も制限されます。 QQ パスワードを変更できますか? QQ ニックネームを変更できますか?個人情報は変更できません。これはどれも変更できず、ハッカーができることは何もないので、問題ありません。
3. サーバーが大規模なユーザーデータ漏洩を引き起こした場合は、運が悪かったと考えてください。バグを修正するにはサービスを停止する必要があります。変更が完了したら、AppKey を再生成して、補償メカニズムか何かを作成するのが安全です。

つまり、それでも許容されます。このメカニズムに問題があったとしても、テンセントはとっくの昔に別の方法を見つけていたでしょうし、あなたが心配する番ではありません。


Tencent が提供するインターフェイスはデータを取得することしかできないことがわかり、以前は注意を払っていませんでした。この方法では、セキュリティ上の懸念がなく、携帯電話がこのインターフェイスを通じてユーザー データを変更できるように、Web サイトのモバイル APP にリクエストを提供するインターフェイスを開発したいと考えています。これを実現する方法はすでにあります。

それを達成する方法を説明していただけますか?

声明:
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。