Webシステムを開発し、Open Id機能の使用を検討しています。ユーザーをログインする通常の方法よりも優れていると思いますか?Open Id機能を使用すると、ユーザーは選択したOpen Idプロバイダーのサイトにリダイレクトされ、より多くのアクションが実行されます。その後、彼らはそこにログインして、私たちのサイトにリダイレクトされなければなりません。ユーザーはこれに満足していますか?
注:これはソーシャルネットワーキングサイトのようなものですが、巨大なものではありません。
Webシステムを開発し、Open Id機能の使用を検討しています。ユーザーをログインする通常の方法よりも優れていると思いますか?Open Id機能を使用すると、ユーザーは選択したOpen Idプロバイダーのサイトにリダイレクトされ、より多くのアクションが実行されます。その後、彼らはそこにログインして、私たちのサイトにリダイレクトされなければなりません。ユーザーはこれに満足していますか?
注:これはソーシャルネットワーキングサイトのようなものですが、巨大なものではありません。
回答:
私はOpenIDが大好きであり、「従来の」サイトごとの資格情報のメタファーよりも絶対に優れています。管理する資格情報を増やしたくないし、Jを信頼したくない 私はそれがより一般的になるにつれて、ユーザーはそれにより快適になると思います。うまくいけば、もっと一般的になるでしょう。
間違っている場合は指摘してください。
ネガティブビュー
肯定的な見解
OpenIDには多くの利点がありますが、その主なものは、認証を怠ることです。認可は依然として問題ですが、少なくとも資格情報を安全に保存することについて心配する必要はありません。これは私の意見では良いことです。「ネットには、serverfaultのような、より多くの「依存パーティ」が必要です。
私は個人的に、OpenIDを愛することに一線を越えました。私はかつて一般的な妄想からそれに対して抵抗力がありました。今では、a $$のすべてをまっすぐに保つにはあまりにも苦痛です。最初は技術系以外のユーザーが苦労するかもしれないことに同意しますが、それが広く普及すればするほど人々がより快適になると思います。一部のサイトでは、従来の(ローカル)認証システムとOpenIDを使用するオプションの両方を提供しています。ここで教育が大いに役立つと思うので、OpenIDが何であるかとその利点を明確に説明すれば、それは受け入れに向けて大いに役立つでしょう。
シングルサインオン(SSO)テクノロジとして、SSOの一般的なリスクにさらされています。その観点から、私はまだ銀行や医療サイトを統合する準備ができていません:)とにかく彼らによって提供されているわけではありません...
OpenIDを使用すると、通常、OAuthが非常に低く抑えられます。
他の人はOpenIDについて十分に詳しく説明しています。OAuthは、他のサイトがあなたのOpenIDプロバイダーを介して誰を知っているかだけでなく、問題のサイトがあなたについて知ることを許可されているかを知ることができるセットに追加します。
大丈夫かもしれません。それらについてはどうですか:
したがって、OpenID + OAuthは、ユーザー名とパスワードを保持するための単一の場所があるだけでなく、自分に関する詳細を保持し、どのサイトがあなたに関する詳細にアクセスできるかについての概要を失うことなく、両方を使用することにより、素晴らしい組み合わせです。
OpenIDがその場で多くのユーザーを獲得するシナリオを考えることができます。主要なサイトが悪意のあるハッカー[*]に対する数百万のユーザーパスワードを失い、リストが漏えいしたとします。特定のアカウントが1つだけでなく、複数のサイトで同じログイン/パスワードを使用しているため、ほとんどのユーザーはパニックに陥ります。そして、彼らはそうします。知ってるよ そして、これらのアカウントを追跡していないため、パスワードを変更することはできません。
今、悪役が私のアカウントを盗むことができると知ったとき、私は何をしますか?パスワードを変更するというこの圧倒的なタスクを乗り越えようとします。または、OpenIDの概念につまずいて、これらすべてのアカウントをその場で変換しようとします。これは、複数のサイトに対して単一のログイン/パスワードを事実上持っていることを意味しますが、すべてのサイトのパスワードを少なくとも簡単に変更できるようになりました。また、悪意のあるハッカーが私のOpenIDを盗む場合、パスワードのリセットを要求するか、少なくともアカウントを無効にするという問題が1つあります。
[*]-読み取り:スクリプトキディ
さまざまなWebサイトにアクセスするほど、シングルサインオン機能が必要になります。
すべてのWebサイトは、最も重要だと考えています。すべてのウェブサイトは、あなたが何かをする前にアカウントを作成することを主張しています。StackOverflow、Serverfault、Wikipedia、WowWiki、Wowhead、MS Forums、CodeProject、CodePlex、on and on、...
彼らはすべて、私が作成する独自のユーザー名、パスワード、および電子メールアドレスをフォークすることを要求します。その後、彼らはありません編集、ダウンロード、クリック、コメント、レートなど、彼らは私が投稿してみましょう前に、私は私の電子メールをチェックしに行くことを主張して何私はそれにさまよう瞬間をあなたのサイトを利用させないための理由は。
黙ってほしいだけです。私はどこでも使用できる単一のログインを望んでいます。電子メールアドレスはブラックホールなので、ゴミを読む必要はありません。
OpenIDはそのようです。しかし、Googleがそれをサポートして初めて可能になりました。それ以前は、StackOverflowが所有する独自のログインシステムでした。彼らは怠けすぎてホストできませんでした。GoogleがOpenIDをサポートするようになったので、実際には誰もが既にそれを持っていると考えられます。
最近では、ウェブサイトでアカウントを作成する必要があり、最初にアカウントを作成する必要があると考えるオペレーターをcur倒します。
私もあなたのサイトを嫌いにしないでください。
両側でopenIdを使用する利点は次のとおりです。1.開発者はログインシステム(データベース、クライアント処理、アプリセキュリティなど)を実装する必要がありません。2.ユーザーは追加の資格情報セットを覚える必要はありません。
一方で、実際にはコンピューターに精通していないユーザーの一部を怖がらせ、サイトにログインするためにGoogleの認証情報を提供するのを嫌がります。
最良の解決策は、OpenIDとオンサイトの登録の両方を可能にするハイブリッドシステムですが、これは私が述べた最初の利点を実際に台無しにします。
OpenIDがユーザーに提供するもう1つのことは、より強力な資格情報を使用できることです。ここでの回答にはフィッシングに関する懸念がありますが、フィッシング可能/再生可能な資格情報をまったく使用しないOpenIDプロバイダーを選択できます。たとえば、一部のプロバイダーではSSL証明書または情報カードがサポートされています。myOpenIDには、ログインする前に電話に出る必要があるというものがあります。ハードウェアトークンを使用するサイトは他にもあるはずです。
はい、ほとんどのユーザーはおそらくYahooボタンをクリックするだけで、それを使用しないでしょう。しかし、それは彼らに選択肢を与え、あなたは実装の詳細を心配する必要はありません。クロスブラウザの方法でSSL証明書をサポートするよりも、サイトにOpenIDサポートを追加する方が簡単だと主張しています。そして、SSL証明書、情報カード、電話検証、トークン検証、DDRpass、ランダムドットステレオグラム認証、または彼らが次に考える奇抜なものすべてをサポートするよりも確かに簡単です。
私は誰かの心を変えようとはしていません。これらの事実を考慮してください。OpenIDは、ユーザー+パスワード認証システムとは2つの異なる点のみです。
私が指摘しようとしているのは、これ以上変更されないということです。
それは他の技術と同じです。人々がそれについて話すことのほとんどは、彼らがそれを研究するために時間をかけなかったか、または彼らが間違った実装を使用したため、神話です。
OpenIDはより複雑であり、ダウンしない他のプロバイダーに依存します。
StackOverflowに伴う問題の1つは、使用している通常のOpenIdとは異なるOpenIdでサインインすると、評価とバッジが失われることです(おそらく修正されており、聞いたことがないかもしれません)。プロバイダーがダウンしたために1時間サインインできなかったことがありました。
私はopenIDが嫌いで、それがserverfault / stackoverflowにサインアップしない主な理由でした。ユーザーのプライバシーはどうですか?私のような一部のユーザーは非常に妄想的で、さまざまなWebサイト間でfacebook / yahoo / google情報を混在させたくない
OpenIDは、概念的にはIMOにとって困難な戦いに直面します。なぜなら、a)開発者が実装するのが難しく、b)URLを使用するという概念に慣れるのが難しいからです。ユーザー名/パスワードの使用パターンは、この時点でかなりしっかりと根付いています。
とはいえ、Clickpass(www.clickpass.com)をご覧ください。彼らは積極的にOpenIDを使いやすくしようとしています。
がんばろう。
未だに。
ブラウザのサポートが必要です。ブラウザはOpenIDで優れたユーザーエクスペリエンスを完成します。これは、IDを一元管理し、物事を非常にシンプルにすることができるためです(訪問しているWebサイトはOpenIDを使用しているようです。http://yahoo.comを使用しますか/ user to login?)およびセキュア。
しかし、現時点では、OpenIDを使用可能にするために多大な努力が必要です。ご覧のとおり、OpenIDをオプションとして提供するか、独自のOpenIDプロバイダーをユーザーに提供する必要があります(サードパーティのサービスを自由に使用できるようにします)。
OpenIDの問題は、ServerFaultのように、誰かのIDに対する信頼レベルが実際に考慮されていない場合に最適です。思いやりを開始すると、生活が複雑になります。
認証プロバイダーを制御するとき、私はそれを実行し、おそらく私が必要とする標準に実装しているため、そのプロバイダーを暗黙的に信頼するため、複雑になります。認証を制御外に移動する場合、認証プロバイダーにも信頼レベルを割り当てる必要があります。
雇用主では、法律により、主要なOpenIDプロバイダーを信頼できません。
それは決して包括的なリストではありません。
OpenIDを非自明なアプリケーションで機能させるには、信頼できるプロバイダーが必要です。ユーザーをその信頼できるプロバイダー(または複数のプロバイダー)に制限する必要があります。そのようなことは、「単一のユーザー名/パスワード」の利点全体を打ち負かします。それでも、より高い信頼レベルのユーザーに対して、何らかのID確認を行う必要がある場合があります。特に、独自の認証プロバイダーを管理するのがロケット科学ではない場合、私には多くの仕事のようです。
IMO、政府はこの技術を機能させる可能性を持っています。州/地方のDMVまたは郵便局が、市民がOpenIDを介してアクセスできるオンライン資格情報を確立するサービスを提供した場合、郵便局/ DMV資格情報を信頼できます。(政府が「私たちを信頼してください」と言うので)ノルウェーやデンマークのような国はすでに個々のPKI資格を発行していると思います。
ソーシャルネットワーキングサイトの場合、OpenIDは技術に精通した人を引き付けるのに役立ちます。ただし、それが唯一の選択肢である場合は、他のすべての人を怖がらせます。ユーザーは、各サイトで新しいログインとパスワードでサインアップすることに慣れています。OpenIDは新しくて外国のものであり、ユーザーに資格情報を第三者に提供している理由をユーザーに不思議に思わせるかもしれません。一般的なユーザーにとって、OpenIDは、GiveMeYourInformationSoICanSpamYouと言うこともできます...それは、サイトの整合性を疑うもう1つの理由にすぎません。
要するに、ユーザーベースを決定し、OpenIDをスクラッチするか、OpenIDとアプリケーション管理ログインシステムの両方を使用します。
なぜ人々はopenIDがより安全だと思うのだろうか。技術に精通したユーザーの場合、これは当てはまるかもしれませんが、一般的なユーザーは実際のopenIDログインと偽造パスワードの違いを見つけられないでしょう。
さらに悪いことに、彼らもこのopenIDアカウントをこのパスワードに関連付ける必要があることを知っており、おそらく単純なユーザー名/メール/パスワードの組み合わせを使用するよりもはるかに大きな損害を与える可能性があります。
openIDは技術ユーザー向けの技術ソリューションであり、一般ユーザーにはあまり役立ちません。そのため、技術的なサイトの場合は繁栄するかもしれませんが、普通のサイトの場合はすぐにはわかりません。
はい、OpenIDはユーザーの観点からは通常のログインソリューションよりも優れていると言えます。これらの理由は次のとおりです。
OpenIDのオプションがあるからといって、ユーザーがOpenIDを使用したくない、または持っていない場合に、従来のユーザー名とパスワードの組み合わせを使用するバックアップオプションを提供できないことを意味しないことに注意してください。プロバイダー。ユーザーが知っていれば自分が望むものを選択できるようにし、それ以外の場合はデフォルトでOpenID、imoに設定しても問題はありません:)
この分野で作業すると、多くのさまざまなログイン資格情報が得られます。OpenIDを使用すると、すでに確立されているアカウントを使用して、別のアカウントとパスワードを設定することなく自分自身を認証できます。多くのサイトがOpenIDをサポートし始めているため、IDを検証するために使用するOpenIDオーセンティケーターの選択肢がはるかに多くなります。
既存の既存のIDを使用したくない場合は、独自のOpenID認証システムを自分のサイトにセットアップすることもできます。これにより、認証されたときにどの情報が提供されるかを正確に制御できます。
アカウントを作成するオプションまたはOpenIDを使用して認証するオプションがあることは、セキュリティへの妄想と使いやすさを求めるものの両方をカバーする素晴らしい組み合わせだと思います。
OpenIDは素晴らしいと思います。私たちはサイトでそれを検討しています。ただし、oAuthが必要であり、ユーザーからのメールも必要です。私たちはそれを広範に使用しており、私たちが行うことの1つは、ニュースレターをメールで送信することです。オプトアウトを許可していますが、システムが機能するためにはそれが必要です。
ユーザー/ pwdを放棄することを嫌う技術者のハードコアグループが存在するようで、それを理解できます。一部はプライバシー擁護者であり、私は完全に理解しています。怠laな人もいれば、ユーザー/パスワードを設定したくない人もいます。彼らはインターネットから情報を取得したいが、とにかく、いかなる方法(広告、コストなど)でも決してお金を払ってはいけない。
あなたのサイト、必要な詳細/情報を調べ、それがあなたのニーズを満たしているかどうかを判断する必要があります。存在する場合は、現在のログインメソッドに加えて追加できます。人々に連絡したり、物事を知らせたりする必要がありますか
自分自身を認証するための中心的な方法を持つことは素晴らしいことですが、前述のように、パスワードの変更/複雑さの欠如という問題があります。しかし、それはサイトの問題というよりもユーザーの問題です。妥協はユーザーレベルで行われますが、解決することはありません。しかし、それは、サイトの所有者として、それが発生しても責任を負わないことを意味しています。
OpenIDで発生する唯一の問題は次のとおりです。
2つの関連サイトを想像してください。どちらもOpenIDログインを許可します。確かに、彼らは互いにアクティビティ統計を共有することができます-たとえば、最初のサイトでアクションXとアクションYを行い、2番目のサイトにアクセスすると、最初のサイトでのアクティビティに応じてターゲット広告で攻撃されます。何らかの理由で、OpenIDログイン間の分離の欠如は、私には少し不快に思えます。
しかし、問題は、OpenIDの究極の利便性(1つ、できればセキュリティで保護された、資格情報のセット)が、前述の欠点によって食われないことです。私は可能な限りOpenIDを使用し、公用のWebサービスを開発するために、OpenIDをサポートするようにしました(おそらく従来の登録オプションを使用します)。