今日、私は、アカウントにリンクされたモバイルデバイスを使用するサイトでの代替認証のアイデアを訪れました。
なぜこれが必要なのですか？
たとえば、ユーザーが2要素認証での使用やパスワードの回復などのためにパスワードを操作するのが面倒な場合などです。
実際、私は本番環境でこのメカニズムを使用する方法については考えていませんでした。 主な目標は実装であり、それから見ていきます。
理論のビット
どのように見えますか？
バインドして認証するには、デバイスで対応するQRコードをスキャンするだけです：
1.バインディングページ
2.ログインページで
何に添付しますか？
ちょっとした「グーグル」ですが、デバイスについてのプライベートな（一意の）情報をウェブから学ぶ方法がないことを悲しみながら実感しました。 IMEIもシリアル番号も、そのようなものはありません。
以下のみが残ります。
1.デバイスのブラウザに存在する長寿命のCookie。
2. IPアドレス
3.ユーザーエージェント
残念ながら、このようなデータでは、デバイスをアカウントに長期間バインドすることは期待できません。
バインディングメカニズム
1.リンクを生成し、QRコードを生成します
2.デバイスはコードをスキャンし、リンクをたどります
3.デバイスに関するあらゆる種類の情報を収集し、コンプライアンスを維持します（デバイス=ユーザー）
4.デバイスにクッキーを掛けます。
5.この時点で、ブラウザは特別なリンクを「リッスン」し、肯定的な応答が受信されるとすぐに、ユーザーへの正常なリンクに関するメッセージを表示します。
認証メカニズム
1.リンクを生成し、QRコードを生成します
2.デバイスはコードをスキャンし、リンクをたどります
3.デバイスに関するデータを収集し、データベースで検索します
4.デバイスが見つかったら、ブラウザでユーザーのセッションを開きます
5.この時点で、ブラウザは特別なリンクを「リッスン」し、肯定的な応答（この場合はCookieと目的のページへのリダイレクト）を受信するとすぐに、ユーザーはログインします。
ソースコード
投稿ではリストを提供しません。興味がある場合は、 githubリポジトリにアクセスしてください。
結論として、追加したいと思います。 メカニズムと可能なユースケースの改善に関する適切なフィードバックを受け取りたいと思います。
コードの品質をあまりoldらないでください。すべてが「ひざの上」で一から書かれています。
PSユーザーエージェントとIPデバイスはデータベースに保存されますが、承認には使用されません。 未来に残しました。
UPD ：分が表示されたら、テストしたい人のためにスクリプトの作業バージョンを投稿します。
UPD2 ：リポジトリを更新しました。 ここでテストしたい人のためにサーバーにスクリプトを投稿しました