私のチームは、サーバーとクライアントを含む Web アプリをコーディングしています。クライアントからのすべての要求をユーザーuidとサーバーに送信することは明らかにお勧めできません。password
私はこれに対処するための良い選択を探しています。おそらく のようなものOauthですが、効率的なアプローチはありますか?
たとえば、ユーザー名lyjとパスワードを持つユーザー123456がクライアント アプリからのログインを要求すると、サーバーはそれが許可されているかどうかを確認する必要があり、ログインが成功した後、クライアントはサーバーから他のリソースを取得するためにさらに要求を送信できます。私の問題は、ユーザーIDとパスワードを除いて、サーバーとクライアントの間にこの男が誰であるかを確認する方法があることaccess tokenです.サーバーとクライアントの間で送信するための提案はありますか?
あなたのプラットフォームとテクノロジーに関する多くの情報がなければ、私は一般的な答えしか試すことができません. トークンの使用方法に応じて、トークンを生成する方法がいくつかあります。MD5は十分に確立されたアルゴリズムであり、ユーザー名や電子メールなどを使用して oth トークンを生成するために使用できます。MD5 文字列を復号化できないことに注意してください。したがって、あらゆる種類の検証を行うには、元のパラメーターを使用して文字列を再作成し、チェックを実行する必要があります。逆にできるハッシュが必要な場合は、base-64 のようなものを見ることができます。
MD6 と base-64 はどちらも、使用しているバックエンドでライブラリとして簡単に利用できます。
* アップデート
ステートレス クライアントで作業しているというコメントを見て、トークンを使用するための可能なアプローチを次に示します。
クライアントは初回ログインを実行します。(できれば HTTPS)
サーバーは検証を実行し、(username+email+ip_address+time_stamp) を使用して MD5 (または選択した他のもの) を使用してトークンを生成し、それをクライアントに送り返します。
サーバーは、 userID 、 ip_address 、および time_stamp を使用して、データベース内のテーブルにこのクライアントの新しいセッションを作成します
クライアントは、今後のリクエストのためにこのトークンを返します。
クライアントがトークンを渡すと、サーバーはデータベースからセッションを取得し、MD5 ハッシュを生成して、クライアントが送信したトークンと比較します。それが同じなら、あなたは良いです。
タイムスタンプ値をトークンの有効期間として使用して、トークンが永久に有効でないようにすることもできます。また、誰かが同じ MD5 ハッシュをミリ秒単位で同時に作成できない限り、このトークンを再作成することは不可能です。
最新の Web アプリケーション コンテナには、セッション トラッキング機能が組み込まれています。もちろん、常にクッキーの選択があります。何を実装するかはあなた次第です...