Web認証：それは何ですか？

Webリソースとその機能の承認/登録の現在知られているすべての「単純な」方法を1か所に集めたいと思います。 （簡単-スマートカード、指紋をスキャンするためのデバイス、網膜などの特別なデバイスを必要としないという意味で）さて、試してみましょう...



現時点では、私はそのような方法を知っています：



1.サイトでの簡単な承認

ユビキタスであり、最終リソースへの登録後にのみ自然に可能であり、実装には通常、ユーザーが提供するログインとパスワードのペアが必要です。

長所：実装の容易さ、信頼性。

短所：サイトごとに、覚えておく必要があり、常に成功するとは限らないさまざまな資格情報。



2. OpenIDによる承認

いわゆる興味深い認証方法を実装するための、かなり興味深い認証方法 「IDプロバイダー」および「依存関係者」-ユーザーを識別しようとしている最終リソース（サイト）。 この方法の特徴は、サイト自体への登録は不要であり、多くのサイトで識別プロバイダーを使用できることです。

詳細については、たとえば、 http ： //ru.wikipedia.org/wiki/OpenIDをご覧ください。

長所： 1つのプロバイダーに共通のログインとパスワードが1つあるため、すべてのリソース、利便性（異なるサイトの多くのアカウントを覚える必要はありません）、使用速度、セキュリティ（プロバイダーのアカウントのパスワードは最終リソースに送信されません（フィッシングの場合を除く） 、傍受も除外されます）

短所：方法はまだ非常に小さく、ほとんどのユーザーが必要とするOpenIDをサポートするサイトは指で数えることができ、集中化も常に良いとは限りません。

メソッドを使用するサイトの例： Learn 、 My Circle

アイデンティティプロバイダーの例： MyOpenID.com

方法のバリエーション：「.NETデジタルパスポート」はMicrosoftの独自開発ですが、配布されています。



まあ、これは多かれ少なかれ人気があります。 「エキゾチック」を考えてみましょう：



3.列挙-承認

メソッドの本質：「アカウント」を携帯電話番号にバインドします。 そのようなプロバイダーのサイトに登録するとき、ユーザーは自分の電話にJavaアプリケーションをインストールするためのリンクを提供されます。 この方法をサポートするサイトでは、承認のために、ユーザーは自分の電子メールアドレスを入力します。応答するサイトは、以前にインストールしたアプリケーションに入力する必要がある番号をユーザーに表示します。 管理番号を入力すると、結果番号が携帯電話の画面に表示されます。この番号は、承認が行われるサイトに入力し直す必要があります。

OpenIDを連想させるものであるため、その機能の一部を継承します。

ソリューションの利点 ：実装と使用の容易さ、セキュリティ（この方法では、再承認に適した資格情報の傍受が排除されます）

短所：盗難または紛失したり、適切なタイミングで近くになかったりする可能性のある、電話へのバインド方法の小さな分布。 列挙型プロバイダーの例



4。

このメソッドに名前を付けるのも難しいと感じています。 ユニバーサルアカウントchtoli。 この方法の本質は、このサイトにコメントを書くには登録済みのアカウントが必要なことですが、必ずしもjabber.ru自体ではなく、一般的にはすべてのジャバーサーバーに必要です。 本当に便利です。

（opusを書いている時点では、メソッドは機能しません。リモートサーバーへの接続エラーがあり、エンジンは入力されたパスワードが間違っているとみなし、gmail.comアカウントで試してみました。

さて、賛否両論で明らかなようです：多くの人が今Jabberを持っている、彼らはアカウントを持っている-それは便利です。 しかし、ここでは、サイトを信頼するという疑問がすぐに生じます。なぜなら、一度ログインするだけで-不正な管理者が再びログインできるからです-これはマイナスです。 また、それにもかかわらず、サイトは「テーマ」と見なすことができ、別のサイトでの同様の方法は、異なる視聴者のために単に不当になります。



5.証明書の承認

コンピューター（同じOpenIDプロバイダー、たとえばMyOpenID.com ）に証明書をインストールすることから、より簡単な方法まで、非常に異なる方法で実装できるという理由で、より詳細にペイントする必要はないと思います... Antichatフォーラムで -通常の登録後、プロファイルにアクセスして「証明書」-キー付きファイルをダウンロードし、人里離れた場所に隠して忘れることができます。 そして、パスワードを紛失した場合にのみ覚えておいてください-証明書は忘れたパスワードのリセットに役立ちます。 最も純粋な形式の承認ではなく、証明書について:) 証明書についても読むことができます 。



6.参照による「1回限りの」承認

例：フォーラムへの通常の登録後、アドレスを確認するリンクが記載された電子メールが指定された電子メールアドレスに送信されます。 リンクは一度だけ機能し、その目的も同じです-そのフォーラムに登録したのはこのアドレスの所有者であることを確認するためですが、時々、そのようなリンクをクリックすると、ユーザーはユーザー名とパスワードを入力せずにすぐにアカウントに入りますが、これも便利です。 パスワードのリセットにも同様の方法が使用されます。 一般に、承認方法でもあります。



結論：

これらの方法のいくつかは互いに多少似ていますが、異なる長所と短所があります。 同時に、2-6メソッドは、最初の「単純な」登録と承認なしでは実行できません。

しかし、私は何のためですか？ また、別のプロジェクトを作成するときは、ユーザーの承認/登録の問題を十分に検討する必要があります。



脅威建設的な批判を待っています。



UPD：

コメントと訂正をありがとうございました。また、議論に積極的に参加できなかったことをおaびします。勉強のために不可能でした。 :)