1つのフォームでの2要素認証
アプリでのGoogle 2要素認証の実装に取り組んでいます。各顧客は、アプリの設定でユーザーの2FAをオンまたはオフにできます。
この機能を微調整するアイデアがありました。 Cookieに保存されている2FA（有効または無効の場合）に関するフラグを持つリピーターを認識し、2番目のステップで入力したGoogleコードを（ユーザー名とパスワードを提供した後に）表示する代わりに、単一のフォームで{ユーザー名、パスワード、認証コード}。
私はこのアイデアを研究しようとしていましたが、そのように使用した人はいないようです。いいアイデアだと思いますか？ログインプロセスを高速化し、1つのフォームのみに制限します。
これは、検討しているオプションをa/bテストする良い機会です！
私は、単一フォームの2要素認証ログインを使用しました。これが、これらのシステムのエンドユーザーとして私が観察したものです。
- ユーザーがログインプロセスを開始するときにすでに2番目の要素を持っている場合は、単一のフォームを使用します。
- 認証プロセスの最初のステップを完了することによって2番目の要素が生成される場合は、マルチステップフォームを使用します。
最初の状況の例は、ATMのユーザーです。認証の2つの要素は、ATMカードとPINです。両方があるため、PIN（技術的には、PIN=のリクエストは、カードをリーダーに挿入することによってトリガーされます。したがって、これは2つのステップと見なすことができます。別の例は、Authyのようなトークンジェネレータを使用しているユーザーです。ログインフォームに到達する前にトークンを取得します。
2番目の状況の例は、テキストメッセージで受信したコードを2番目の要素として使用してGmailに認証することです。そのような状況では、ユーザー名とパスワードが入力されたときにコードを知ることはできません。これは、最初の認証要素が確認されるまでコードが送信されないためです。
単一のフォームを使用できる状況の場合は、必要な情報ごとにどのデータ入力フィールドがあるかについてフォームが明確になるように特に注意してください。トークンジェネレーター（またはアプリのアイコン）の写真を貼って、ユーザーにトークンの入手先を思い出させることを検討してください。
直観に反すること>ユーザーが2要素に分かれた場合、ユーザー名とパスワードはすでに正しいため、ログインから2要素に移動し、UXの懸念を分離するために別々のフォームになっています。
私はgoogle 2FAを使用していませんが、パスワードフィールドがあると思います。コードを入力するとき、彼らは通常、パスワードを再入力する必要があるので、1つのフォームに2つのパスワードフィールドが表示されます。これは理想的ではなく、おそらく見栄えも良くないでしょう。
2FAを使用するほとんどのシステムは、2つの認証ステップを使用します。最初にユーザーのログインとパスワードが確認され、次にユーザーはSMSまたは電子メールで送信されたトークンによって生成されたOTPを入力します。
最初にシステムがログインとパスワードが正しいかどうかをチェックするため、2つの形式が一般的に使用されます。その後、ユーザーはOTPに入る2番目のフォームに転送されます。
署名には、ログイン、パスワード、およびワンタイムパスワードを使用する単一のフォームを使用できます。たとえばJoomlaなど、一部のサービスはすでにこのアイデアを使用しています。