私のウェブサイトは、機能を拡張したアプリを作成しています。つまり、われわれが自信を持っているので、厳密なOAuthプロセスに従う必要はありません。ユーザー名/パスワードをクリアに送信するのは安全ですか？
アプリのユーザーがアプリ内からユーザー名とパスワードを入力できるようにする...つまり、その情報をウェブサーバーに転送して認証する方法が必要です。
私たちがSSLを使用しているとしますが、これは安全な考えですか？
追加の手順が必要なのですが、偽装されたアプリではなく、アプリからのリクエストであることを何とか保証する必要がありますか？
はあなたが心配するかどうかを決定することができますこれらはいずれも、いくつかの可能なセキュリティ上の脅威、ありますhttp://xkcd.com/538/
しかし、セキュリティの原罪「は平文でパスワード」です。少なくともそれをハッシュして、サーバー上にクリアに格納されないようにしてください。
確かにサーバー上でハッシュしています。私はそのリンクを確認します:) – johnnietheblack
次のステップは、クライアントとサーバーの間でハッシュすることです。ウェブサイトにセキュリティ保護されていないWiFi経由でアクセスする場合は、http：//xkcd.com/341/ –
OPによると既にSSLを使用しています。 – Venge
まず、自分自身を信頼するだけでは不十分です。あなたのアプリ、それが使用されているデバイス、またはそれがあなたのユーザーの手に入ると接続されているネットワークを制御することはできません。
あなたのアプリケーションを保持するユーザーがリバースエンジニアリングを行う可能性があるため、あなたのアプリケーション内で共通の共有キーを使用して解読できるのは、（コメントで示唆されているように）他のユーザーをターゲットにするためにそのキーを取得します。
ウェブサイトの認証にシングルサインオン（SSO）を使用せず、フォーム内のプレーンなユーザー名とパスワードを使用する場合は、アプリケーションからSSL/TLS接続を介して送信することも同じですブラウザから（HTTPS経由で）、全体的な設定が正しいことを条件にします。とにかくブラウザからフォームを投稿すると、これはすでに起こります。 SSL/TLSを使用することで、実際にパスワードをクリアに送信することはできません（適切に設定されている場合）。
あなたのアプリケーションやスプーフィングされたアプリから来ているかどうかを確認することは別の問題です。これは一般的に防御するのが非常に難しいです。あなたのサービスがうまく設計されていれば、とにかくユーザー認証を既に持っていると価値がないことがよくあります。認証済みのユーザーは、サーバーから許可された操作（サーバーがアプリが正常に認証されたことをサーバーが確認している限り）を実行する必要があります。 （この場合、サービス自体ではなく、スプーフィングアプリはユーザー自身にとってより問題になりがちです）
私は決してそうしません。ユーザー名/パスワードを暗号化して送信するのはあまりにも簡単です。 –
それで、プロセスは... 1。ユーザーはユーザー名/パスを入力します。2.私のアプリケーションは送信を暗号化します。3.情報はサーバーに送信されます。4.サーバーは何らかの形で暗号化されたデータを検証しますか？ – johnnietheblack
SSLを想定すると、暗号化はすでに行われています。問題はアプリからのものであることを確認するためにリクエスト自体を検証しています。 – mrlee