二要素認証は、ユーザー側にとっては非常に平凡なプロセスに思えるかもしれません。多くのアプリケーションを使用する際、使い慣れたログイン名とパスワードの組み合わせを入力するだけでは不十分であることに、多くの人が長い間慣れ親しんできました。不正なアクセスを防ぐために、セキュリティのために追加の認証要素が導入されます。多くの場合、それは電子メールやSMSで受け取ることができる一意のコードです。
このチュートリアルでは、AppMaster で二要素認証を実装する方法を学びます。例として、メールにコードを送信する方法が使用されます。どのモジュールを接続する必要があるか、どのような設定を行うか、どのようなビジネスプロセスを作成するか、そして実際にどのように仕上がりを確認するかについて分析します。
まず、大まかな計画を見てみましょう。ビジネスプロセスでは、どのようなステップを実装する必要があるのでしょうか。
- ログイン確認（実際に登録されているか確認する）。
- パスワードが正しいかどうかを確認する。
- メールやSMSで確認コードを送信する。
- コードの関連性をチェックする。
- コードの正しさをチェックする。
- 認証の完了
準備段階
二要素認証の設計を始める前でも、ユーザー登録の段階で、以下のことを確認する必要があります。
- ユーザーデータには必ず電子メールが含まれていること。これは、認証コードの送信に使用されます。電子メールはしばしばログインに使用されますが、ここではそのような例を見てみましょう。
- ログインは一意であること。同じログイン名で2人のユーザーがシステム上に存在することはできません。
これらの(そして他の多くの)タスクを解決するのに便利なように Authモジュールは、AppMaster の各プロジェクトにデフォルトでインストールされます。これには、必要なデータベースモデル、ビジネスプロセスブロック、およびそれらを使用するためのエンドポイントが含まれています。
ログインの確認
ログイン、パスワード、検証コードは、ビジネス・プロセスの入力パラメータとして使用されます。しかし、最初の段階では、ログインだけが必要です。このユーザーが存在することを確認するのに役立ちます。彼は登録されており、それに関する情報はデータベースに保存されています。
これを実行するために DB: Search Userブロックは、データベースで指定されたログインを持つユーザーを検索します。パラメータを必ず設定してください。 SearchExact = Trueパラメータを設定して、完全に一致するユーザーを検索するようにしてください。
受信したデータは Array Elementブロックに渡されます (カウントはゼロから始まり、 見つかった唯一の値は常に配列のインデックス 0 に対応します)。
ブロックは Is Nullブロックは、ユーザが実際に見つかったかどうかをチェックします。そして、その結果(True/False)に応じて If-Elseブロックはエラーメッセージでビジネスプロセスを中断させるか (Raise Errorブロック)でビジネスプロセスを中断させるか、さらにその先を指示します。
パスワードの確認
この段階では、ユーザーのパスワードが正しく入力されていることを確認する必要があります。
そしてここで、パスワードはデータベースに明示的に保存されないことを理解することが重要です。そのため Bcrypt関数はパスワードをハッシュ化し、その結果のハッシュのみがデータベースに保存されます。したがって、仮にデータ漏洩が発生したと仮定しても、攻撃者がユーザーのパスワードを見つけることはできません。
このため、単純にデータベースからパスワードを取得して、入力されたパスワードと比較することはできない。パスワードのハッシュを取得して、それを比較に使う必要がある。この問題を解決するために Auth: Probe Passwordブロックを使用します。入力パラメータとして、ユーザーが入力したパスワード(password)と、データベースに保存されているパスワードのハッシュ(hashed_password)を受け取り、String データ型に変換する(the To Stringブロック)に変換します。
その結果に応じて、前のステップと同様に、ブロックを使って If-Elseブロックを使用して、エラーメッセージを表示するか (Raise Error,Message = Password is wrong)を表示するか、次のステージに処理を誘導する。
ユーザーモデルの拡張
次のステップでは、ユーザーモデルを少し変更し、確認が必要なコードに関する情報を追加する必要があります。
一般に、User モデルには、このタスクに使用できるフィールドが初期に含まれています -Confirmed, Confirmation code, Confirmation code expires at 。しかし、この例では、これらのフィールドは、登録と最初のアカウント確認にのみ使用されると仮定します。
プロセスをより明確にするために、twofa (two-factor authentication) モデルを別に作成し、User モデルをそれに関連付け (1 対 1 の関係、has one) 、1 つのフィールド -code (String 型 ) を追加してみましょう。
メール送信の準備
確認コード付きの電子メールを送信するには、事前に準備する必要があります。最も利用しやすいオプションのひとつは Custom SMTPモジュールを使うことです。
Gmail を使う場合、ほとんどの設定はすでにデフォルトで設定されており、ユーザ名とパスワードを追加する必要があります。他のメールサーバを使用する場合は、そのメールサーバのマニュアルを参照して、必要なデータを入手するとよいでしょう。
この場合、メールサーバーのセキュリティ設定を若干変更する必要があるかもしれません。例えば、Gmail は、デフォルトでサードパーティアプリケーションを使用した接続をブロックしている場合がありますので、設定でこの制限を解除する必要があります。
認証コードの送信
ログインとパスワードの確認、必要な準備はすべて完了しましたので、あとは確認コード付きの手紙を送信する作業に進みます。
この Custom SMTP: Send Emailブロックは、宛先としてアドレスの配列を使用します。したがって、たった一つのアドレスに手紙を送る必要がある場合でも、そのアドレスは配列に追加されなければなりません。そのために Append Arrayブロックを使用します。
次に、検証コードの生成です。そのためには Random stringブロックはこれに適しています。6個の乱数からなるコードを送信し、適切な設定を行うことにする。Length = 6, With 0-9 = True, 他のすべてのパラメータ =False.
次に、手紙のテキストを作成する必要があります。これを行うには Concat Stringsブロックを使って生成されたコードに説明文を追加し (First = Verification code: ) 、その結果をText データ型に変換し (To Textブロック)に変換し、その結果をメール送信ブロックの bodyパラメータをメール送信ブロックのパラメータに接続します。
最終的な送信は、手紙の件名(subject)と差出人(from_name)を指定するのみです。
しかし、コードを送信するだけでは不十分で、ユーザーのデータにも保存する必要があります。何しろ、ユーザーがコードを受け取り、確認として送り返すときに、その正しさを検証する必要があるのですから。
これを行うには、先ほど慎重に作成したtwofa モデルを使用します。もしこれが最初のコード送信であれば、どのユーザーのものであるかという情報を含めて作成する必要があります。再利用の場合は、既存のエントリにパッチを当て、その ID と新しいコードを示す必要があります。
ステージの最終段階では Raise Errorブロックを使用して、電子メールへのコード送信に関するメッセージを返すことです。
コードの関連性チェック
さらなるセキュリティに気を配り、ありきたりな列挙からコードを保護することは価値があります。入力の試行回数や頻度、提出されたコードの有効期限を制限するのが賢明でしょう。セキュリティの要件はプロジェクトごとに異なり、多くの異なる条件が含まれる可能性があるため、これらの例すべてを分析することはしません。ここでは、コードの有効期間による関連性のチェックに限定します。
を使ってみましょう。 Current date & timeブロックを使って、現在の時刻を取得してみましょう。のB パラメータに接続します。 Date & time differenceブロックのパラメータに接続します。をパラメータとして使用します。 UpdatedAtフィールドをパラメータA としてtwofa モデルで使用します。
その結果、次のような結果が得られます。 Time span- 2つの時点の差分が得られます。あとは、この差がある選択された値を超えているかどうかをチェックするだけです。この例では、これは5分であり、ブロックの静的値B として設定します。 Greaterブロックの静的な値として設定します。
この If-Elseブロックは比較結果を利用して、さらに処理を進めます。もし True(差が5分を超えた)場合、プロセスは手紙を送るステップに戻り、ユーザーは更新されたコードを受け取ります。の場合 False(コードが新鮮で最新である)場合、このコードのチェックに進むことが可能になります。
コードレビュー
認証の最終段階は、受け取ったコードをチェックすることです。
この Equalブロックは、ユーザーによって渡されたコードが、ユーザーに関連付けられたtwofa モデルに格納されているコードと一致することを検証する必要があります。もしこれが一致せず、コードの指定が誤っている場合(If-Else -> False)、エラーメッセージを表示する必要があります(Raise Error, Message = Code is wrong).比較の結果、一致が確認されれば、最終的な認証段階に進むことができます。
これを行うには Auth: Authenticationブロックを使用して、ユーザに関する情報を認証トークンとともに取得します。に渡します。 Endブロックに渡します。
エンドポイントの作成
ビジネスプロセスは作成されましたが、まだ使用することはできません。このビジネスプロセスを実行するエンドポイントを作成する必要があります。
妥当な解決策は、デフォルトの認証エンドポイント (POST /Auth) を使用することでしょう。そのビジネスプロセスを置き換えて、先ほど作成したものをインストールすれば十分でしょう。このように、単純な認証は無効になり、代わりに二要素認証が使用されるようになります。
公開とテスト
これで2要素認証の作成は完了です。作成した結果を公開し、実際に動作を確認することができます。そのためには、Preview ボタンのProject API セクションにある Deploy プラン名をクリックすることでアクセスできるSwagger を利用すると便利です。
あとは、リストの中から目的のエンドポイントを見つけて、ユーザーデータを入力し、Execute ボタンで実行を開始するだけです。テスト中にエラーが見つかった場合は、ビジネスプロセスに戻り、必要な変更を行います。
