web-dev-qa-db-ja.com

iOSの「メールでログイン」画面で本当にパスワードを要求する必要がありますか？

ユーザーがメールでログインするiOSアプリのログイン画面を設計しています。

標準的なアプローチ

これが、ほとんどのアプリで使用されているアプローチです。

enter image description here

  1. まず、一般的な「電子メールでのログイン」画面には、電子メールとパスワードの2つのフィールドがあります。
  2. 次に、アプリが新しいアカウントを作成している場合、または既存のアカウントにサインインしている場合に、ユーザーと通信します。これは通常、「ログイン」と「アカウントの作成」の2つの画面を作成するか、「ログイン」と「アカウントの作成」の2つのボタンを備えた1つの画面を使用して行われます。
  3. 次に、確認メールがユーザーに送信されるときに、一部のアプリはメール検証を実装します。これは、ユーザーが有効で有効なメールアドレスを入力したことを確認するために行われます。
  4. 最後に、通常はさらに2つの画面パスワードのリセットがあります。1つはユーザーがメールアドレスを入力する画面で、もう1つは新しいパスワードを入力する画面です。

パスワードフィールドのない簡略化されたログイン

enter image description here

パスワードを削除できますか？

ログイン画面でなぜパスワードを要求する必要があるのか​​と考えていただけですか？奇妙に聞こえるかもしれませんが、説明させてください。

1つのメール画面と1つの「ログイン」ボタンを備えた1つのログイン画面しかなかった場合はどうなりますか？提案されたワークフローは次のとおりです。

  1. IOSアプリのユーザーは、メールアドレスを入力して[ログイン]ボタンをタップします。
  2. サーバーは、指定された電子メールで既存のユーザーレコードがあるかどうかを確認します。ない場合は、新しいユーザーアカウントを作成します。また、サーバーは有効期間が短いシークレットトークンを作成し、ユーザーが電子メールからのリンクをタップしたときにチェックされます（以下を参照）。
  3. サーバーはこのメールアドレスにメールを送信します。メール本文には「ログイン」リンクがあります。リンクにはアプリのカスタムURLスキームがあり、シークレットトークンが含まれています。リンクのURLは次のようになります：myapp：// login/2a9f1939f281a277b1。
  4. iOSアプリに「[email protected]アドレスにメールが送信されました。読んでログインしてください。」というメッセージが表示されます。
  5. ユーザーはメールを開き、iOSアプリを開く「ログイン」リンクをタップします。このリンクは一度だけ使用できます。
  6. iOSアプリは、ユーザーがログインしているデータベースのシークレットトークンと一致する場合、サーバーにシークレットトークンを送信します。

「ログイン」ボタンをタップした後に表示されるメッセージ

注：ダイアログの[メールを読む]ボタンをクリックすると、iOSのメールアプリが開きます。デモアプリを作成し、確実に動作することを確認しました。

enter image description here

ユーザーに送信されたメール

enter image description here

以下は、同僚やここで回答した人たちの助けを借りて収集した長所と短所です。

長所

  1. ユーザーはパスワードを覚えておく必要はありません。忘れることはありません。
  2. ユーザーはログインするために電子メールを受信する必要があるため、電子メールが正しく入力されていることを常に確認できます。これは、私の考えでは、このアプローチの最も強力な機能です。これにより、人々が誤って入力された電子メールアドレスでアカウントを作成し、後でログインできない場合がなくなります。誤って入力したメールは、ユーザーを苛立たせ、不必要なサポートコミュニケーションをたくさん作成する可能性があります。
  3. より安全かもしれません大多数のユーザー向け承知のとおり 多くの人々が共通の/弱いパスワードを使用したり、多くの異なるアプリやWebサイトで同じパスワードを再利用したりする可能性があるため。これにより、スクリプトの子供はユーザーになりすまして、一般的なパスワードを試すか、他のサービスから漏洩したパスワードを使用してアプリにログインできます。
  4. コード、バグが少なく、メンテナンスが簡単です。
  5. UIの削減-1つの画面に1つのテキストフィールドがあります。別個の新規/既存のユーザーを作成したり、パスワード画面を忘れたりする必要はありません。
  6. 「アカウントの作成」画面で「このメールはすでに登録されています」というエラーが返された場合に プライバシーの問題 が表示されなくなり、攻撃者がサービスにアカウントを持っているかどうかを確認できます。

短所

  1. ログイン画面にパスワードフィールドが表示されることに慣れているため、これは直感的ではないかもしれません。パスワードのないログイン画面は奇妙で見慣れないものに見えるかもしれません。個人的にはこれが最大の問題だと思います。なじみのないものは人間にとって恐ろしいものです。
  2. パスワードフィールドは、人々に安心感を与えるかもしれません。パスワードフィールドがないと、安全性が低下する可能性があります。
  3. コンテキストの切り替え？ユーザーがログインするには、メールアプリを開く必要があります。 Counterargument：標準ワークフローへの登録時に電子メールの有効性を確認する場合、ユーザーはとにかく電子メールを開きます。
  4. 安全性が低いですか？電話またはその人のメールにアクセスできる他の人はログインできます。Counterargument：標準のワークフローに同じ問題があります。メールにアクセスできる場合は、[パスワードを忘れた]をタップしてメールを取得し、変更してくださいパスワードとログイン。
  5. ユーザーがメールを誤って入力した場合はどうなりますか？システムは、入力ミスのメール用に新しいアカウントを作成します。 Counterargument：ユーザーが電子メールアドレスを誤って入力した場合、電子メールメッセージを受信できず、ログインできません。ユーザーはearlyユーザーがそれを知っている標準的なアプローチでのメールのタイプミスとは対照的に何かが正しくないことを知っていますlaterすでにタイプミスしたアカウントへのアクセスを失った後データが入力されます。
  6. 誰かのメールを知っていて、自分のデバイスで使用した場合はどうなりますか。 Counterargument：ワークフローでは、メールを読んで、その中の「ログイン」リンクをタップする必要があります。ユーザーのメールにアクセスできない場合は、ログインできません。
  7. ユーザーがログインするたびに、電子メールを開く必要があります。 Counterargument：これは真実ですが、iOSでは、意図的にログアウトしたくない場合を除いて、通常、アプリに長時間ログインしたままになります。
  8. ユーザーがメールを読むことができない場合は、ログインできません。

不足しているものはありますか？この「パスワードなし」のアプローチには他に欠点はありますか？

電話番号でログインしますか？

パスワードなしのアプローチは、「電話番号でログイン」方式でも使用できます。ロジックは同じですが、ログインリンクを電子メールで送信する代わりに、SMSでユーザーに送信する点が異なります。サーバー側のロジックの大部分を再利用して、電子メールと電話番号のログインをサポートできるため、開発者にとっては便利です。

この議論を続けましょう•ᴥ•

このディスカッションにご協力いただき、誠にありがとうございます。新しいアプローチについて話し合って試してみて、それらがどのように機能するかを確認することが重要だと思います。パスワードなしのアプローチを実装した経験がある場合は、ここで結果を共有してください。

参考文献

interaction-designioslogin
4
Evgenii

あなたの提案は実際に複雑になりますユーザーのためのもの

現在のユーザーインタラクション：

  • メールを入力
  • パスワードボックスをタップ
  • パスワードを入力
  • [ログイン]ボタンをタップ

提案されたユーザー操作：

  • メールを入力
  • パスワードボタンをタップ
  • 通知を待つ
  • 通知をタップしてアプリを切り替えます
  • ログインボタンをタップ

あなたの考えは、「単一の画面」しかないということですが、メールに行ってログインアプリに戻るのは本質的に2つの画面切り替えであるという事実を見落とします。 1つのインタラクション（パスワード）をドロップしていますが、いくつかのインタラクションを追加しています。コンテキストを切り替えるインタラクションも同様です。

他の欠点？たくさんあります。

  • あなたは彼らのメールに依存しています。ダウンしている場合、ログインなし
  • セキュリティの低下。電話やメールでアクセスできる人なら誰でもアプリにアクセスできます。 PW /検証を使用しているため、おそらくこれは望ましくありません
  • jeromeRが述べたように、タイプミスの扱いにくい処理
  • アプリとサーバー間の1回ではなく複数回のトリップ
  • メール/ OSのアプリ起動機能に依存しています。すべてのクライアント/プラットフォームがこれをサポートしているわけではありません（まあ）
10
PixelSnader

Mediumはパスワードなしのルートを採用しており、一部の人が言っていることにかかわらず、それは確かに実行可能です。議論の余地がありますが、本質的に彼らがしていることは、セキュリティの焦点を電子メールプロバイダーに移し、ログインするたびにリンク/電子メールを送信して、何か異常なことがわかるようにすることです。私にとっては悪いUXのように聞こえます：

  • 人々のメールアカウントをゴミ（Linkedinか何か）で埋め尽くしてしまう
  • 人のメールアドレスが安全でない場合、それはとにかく無意味です
  • パスワード認証はサービスにアクセスするための長い確立された方法であるため、ユーザーを当惑させます。

そうは言っても、アイデアに関する記事をチェックする価値は間違いありません。

https://medium.com/the-story/signing-in-to-medium-by-email-aacc21134fcd

2
Chris