1. インターフェイスはキーとユーザー ID の md5 暗号化を使用します。次に、暗号化された署名がパラメータとして渡されます (このような単純な暗号化方法は安全ですか?)。
2. ここで問題が発生します。ユーザーのリクエストがキャッチされた場合、他の人もそのリクエストをシミュレートできます。では、リクエストが自分の APP によって発行されたものであることはどのようにしてわかるのでしょうか?
リクエストにアプリ情報のみが含まれている場合は、他の人もそれをシミュレートできます。
3. インターフェイスはアプリから送信されるため、ユーザーはローカル パッケージを取得することによってのみこの情報を確認できます。現在、ユーザーは他の人からパッケージをリクエストされやすいですか?
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
Web API の通信セキュリティを保護するために SSL を使用することを強くお勧めします。独自に実装することは悪いことではありませんが、SSL ほど安全ではありません。あなたのアプローチは仲介者によって監視され、サインは直接悪用されます。
リクエストをシミュレートできます。相手がアプリを逆コンパイルし、認証プロセスを理解している場合は、間違いなくシミュレートできます。
SSL 保護がない場合、http はクリア テキストで送信されます。この状況はローカルでのみ監視できます。 SSL を使用して通信のセキュリティを保護すると、仲介者によって通信が監視されないようにすることができます。表示されやすいかどうかはアプリの価値によって決まります。
詳細を学ぶための主題を推奨します: 中間者監視とリプレイ攻撃
キーを取得するための特別なインターフェイスがあり、キーは 2 日間有効です。
すべてのインターフェイスを調整した後、トークンはキーと対応するパラメーター形式を直接使用して、MD5 暗号化を実行します。つまり、パラメータにはキーがありません。
一般的に、パッケージは何度もリクエストされ、パラメーターは変更され、トークンは異なります。
また、鍵を手に入れても、相手がどのように組み立てるかが分からなければ意味がありません。
Json Web Tokenを試すことができます