私の Web サイトでは、機能を拡張するアプリを作成しています。つまり、アプリは厳密な OAuth プロセスに従う必要はありません。
アプリのユーザーがアプリ内からユーザー名とパスワードを入力できるようにしたいと考えています...つまり、その情報を Web サーバーに転送して検証する方法が必要です。
SSL を使用していると仮定すると、これは安全な考えですか?
追加の手順を実行する必要がありますか?また、リクエストがなりすましアプリなどではなく、アプリからのものであることを何らかの方法で保証する必要がありますか?
まず、自分を信頼するだけでは十分ではありません。ユーザーの手に渡ると、アプリ、アプリが使用されているデバイス、アプリが接続されているネットワークを制御できなくなります。
サーバーのみが解読できる共通の共有キーをアプリ内に持つスキーム (コメントでほのめかされているように) は、アプリケーションを手に入れたユーザーがそれをリバースエンジニアリングして取得する可能性があるため、依然として問題を引き起こす可能性があります。他のユーザーをターゲットにするためのキー。
Web サイトへの認証にシングル サインオン (SSO) を使用していないが、フォームでプレーンなユーザー名とパスワードを使用している場合、アプリケーションから SSL/TLS 接続を介してそれを送信することは、ブラウザーから送信する場合と同じです。 (HTTPS 経由)。ただし、全体的な構成が正しい場合に限ります。とにかくブラウザからフォームを投稿すると、これがすでに起こっています。あなたが提案するようにSSL / TLSを使用することにより、実際にはパスワードを平文で送信していません（適切に構成されている場合）。
それが自分のアプリケーションからのものなのか、偽装されたアプリからのものなのかを確認することは別の問題であり、一般的に防御するのは非常に困難です。サービスが適切に設計されていても、ユーザー認証が既にある場合は、多くの場合、その価値はありません。認証されたユーザーは、サーバーが実行を許可するアクションのみを実行できる必要があります。これらのアクションの要求が、あなたのアプリからのものであっても、これらのユーザーによって制御されている別のアプリからのものであっても (サーバーが正しく認証されていることを確認する限り)。(なりすましアプリは、この場合、サービス自体ではなく、だまされて使用するように仕向けられた場合、ユーザー自身にとってより大きな問題になる傾向があります。)
考えられるセキュリティ上の脅威はいくつかありますが、いずれも心配するかどうかを決めることができます：http: //xkcd.com/538/
しかし、セキュリティの原罪は「明確なパスワード」です。少なくとも、サーバーのクリアに保存されないようにハッシュします。