👰 🙀 🗼 Meteor.jsの2要素認証 ℹ️ 🎐 🗳️

しばらくの間、私はスタートアップで働く機会がありました。バックエンド（およびフロントエンド）として、Meteor.jsを使用しました。ある時点で、2要素認証を実装する必要に直面しました。この記事では、Meteor.jsでこの機能を実装する方法についてお話したいと思います。

カットの下には、単一のスクリーンショット/画像はありませんが、実装に必要なすべてのコードが表示されます。

エントリー

私たちの場合、2番目の要因は、Twilioを介して送信されるSMSメッセージのコードでした。あなたの多くは、SMSメッセージの形式の2番目の要素は無駄であり、愚かであることを叫ぶでしょう。このTFA実装では、2番目の要素を使用できます。私の意見では、それらを戦略として公式化し（必要に応じて）、必要に応じて接続することが理想的ですが、私はそれを達成できませんでした。 Meteor.jsプラットフォームでの機能の実装に特に焦点を当てます。

最初の要素の入力に成功すると、時間制限のあるセッションが開き、2番目の要素を入力することで完了する古典的なアプローチを実装しました。

Meteor Accountsパッケージには認証を一時停止する方法はありませんが、コードを生成して送信し、ユーザーに入力する時間を与えるために、この一時停止が必要です。したがって、標準のMeteor.loginWithPasswordメソッドを放棄し、ドキュメントにはないMeteor.loginWithTokenメソッドを使用する必要があります。このメソッドを使用すると、ユーザーは、MongoDBに既に生成および保存されているトークンを使用してシステムで認証できます。

行動方針

手順：

LoginProcedureを呼び出すMeteorメソッドで認証プロセス全体を置き換えます。
最初の要素とすべての種類のチェックの検証。
2番目の要素（コード）を生成し、Twilioを使用して送信します。このステップは、2番目の要素とその配信を生成する任意の方法に置き換えることができます。
コードとその他のデータを別個のMongoDBコレクションに保存し、オープン認証セッションを保存します。
クライアントがユーザーに2番目の要素を入力するように要求する中間結果を返します。
2番目の要素の受信と確認。
新しいトークンを生成し、クライアントに返します。
クライアントは、受信したトークンを使用してloginWithTokenを自動的に実行します。

手順1〜2

Meteorメソッドを認証に使用するのは簡単ですが、ユーザーが標準のloginWithPasswordを使用できないようにする方法はありますか？

Accounts.validateLoginAttemptメソッドがあり、各認証操作を「承認」する必要があります。引数は、 methodName属性とtype属性に関心がある試行オブジェクトを取得します。 loginWithTokenメソッドの場合、これらの属性にはそれぞれログイン値と再開値があります。また、電子メールでアカウントを確認し、パスワードを回復した後、認証を許可する場合は、 methodNameの追加の値を「承認」する必要もあります。結果は次のメソッドです。

Accounts.validateLoginAttempt(function(attempt){ var allowed = [ 'login', 'verifyEmail', 'resetPassword' ]; if (_.contains(allowed, attempt.methodName) && attempt.type == 'resume'){ return true; } return false; });

新しいトークンを生成するための関数をすぐに記述します。これらの関数は、ドキュメントに含まれていないいくつかのメソッドも使用します。そして、ここにコードがあります：

 var generateLoginToken = function(){ var stampedToken = Accounts._generateStampedLoginToken(); return [ stampedToken, Accounts._hashStampedToken(stampedToken) ]; }; var saveLoginToken = function(userId){ return Meteor.wrapAsync(function(userId, tokens, cb){ // In tokens array first is stamped, second is hashed // Save hashed to Mongo Meteor.users.update(userId, { $push: { 'services.resume.loginTokens': tokens[1] } }, function(error){ if (error){ cb(new Meteor.Error(500, 'Couldnt save login token into user profile')); }else{ // Return stamped to user cb && cb(null, [200,tokens[0].token]); } }); })(userId, generateLoginToken()); };

Accounts._generateStampedLoginTokenメソッドは、将来loginWithTokenメソッドを実行するためにクライアントに返される必要がある新しいトークンを返します。 Accounts._hashStampedTokenメソッドはトークンをハッシュし、MongoDBに保存する必要があるのはハッシュ形式です。

Meteorメソッドに戻りましょう。そして、ここにコードと説明があります：

 Meteor.methods({ 'LoginProcedure': function(username, pswdDigest, code, hash){ //Here perform some checks //I'll leave it up to you //Something to prevent NoSQL-Injections etc. ... //Now check if user already exists var user = Meteor.users.findOne({ '$or': [ { 'username': username }, { 'emails.address': username } ] }); if (!user) throw new Meteor.Error(404, 'fail'); //Now password checks //Explanations about this are right after the code var password = {digest: pswdDigest, algorithm: 'sha-256'}; var pswdCheck = Accounts._checkPassword(user, password); if (pswdCheck.error) throw new Meteor.Error(403,'fail'); //Next check if two-factor is enabled //If it's not, just generate token and return it //Else start the procedure... if (!user.twoFactorEnabled){ //Use function defined above return saveLoginToken(user._id); }else{ //Step 3-7 ... } } });

ご覧のとおり、ドキュメントに記載されていない別の方法。

すべての認証を手動で実行するため、パスワードも手動で確認する必要があります。問題は、Meteorがどのようにそれらをハッシュするかわからないことです。これはまさにAccouts._checkPasswordメソッドの使用目的です。引数として、先にMongoDBから取得したユーザーレコード、およびユーザーのパスワードハッシュとハッシュメソッドを含む別のオブジェクトが彼に渡されます。常にsha-256です。

ハッシュ自体は、Meteorメソッドを呼び出す前にクライアント側で実行されます。使用される標準の方法はPackage.sha.SHA256（ ''）です。

また、TFAが無効な場合のアクションコースについても説明します。新しいトークンを生成し、クライアントに返すだけで、そこからMeteor.loginWithTokenが呼び出されます。

Meteorメソッドの引数の数を明確にしたい-同じメソッドを使用して、認証セッションを開いて終了します。

ハッシュ引数は、すでに開いているセッションを追跡するためのものです。ユーザーが認証セッションを開いてからブラウザー/タブを閉じたが、コードを含むSMSが既に送信されているとします。そして、1分（セッションの有効期間）以内に、彼は再び認証セッションを開き、SMSが再度送信されます。それはお金の純損失になります。したがって、（最初の要素を渡した後）オープンセッションの場合、ハッシュが作成され、それに接続されてMongoDBに保存され、クライアントに返され、そこでlocalstorage / cookieに保存されます。そして、クライアントは再び起動するとき、その時間推定に従って、最後の認証セッションが生きているかどうかをチェックします。生きている場合、彼はこのハッシュを最初の要素（ユーザー名、パスワード）と共に添付します。また、さまざまなデバイスからTFAセッションを開くこともできます。このプロセスについては、次のステップで詳しく説明します。

ステップ3-5

これらの手順には、2番目の要素自体が含まれます。

MongoDBに、オープン認証セッションを含む特別なコレクションを作成しましょう。 TwoFactorSessionsと呼ばれるとします。 Meteorのサーバー側でのみ定義する必要があります。

そして、ここにコードがあります：

 Meteor.methods({ 'LoginProcedure': function(username, pswdDigest, code, hash){ //Steps 1-2 ... if (!user.twoFactorEnabled){ //Steps 1-2 ... }else{ if (code && hash){ //Step 6-7 ... }else(hash){ //That part is for continuing previous session //New code will not be sent, but client-side app //will receive special response code and open the pop-up var session = TwoFactorSessions.findOne({ hash: hash, username: username }); if (session){ //Lets use some imaginary validation function //that you will define by your own in your project validateSession(session, user); return [401, hash]; }else{ // Couldnt find, return error throw new Meteor.Error(404, 'No session'); } }else{ //Generated code, i'll leave it up to you var newCode = <code here>; //The now date can be used as hash, just timestamp var now = new Date(); var hash = +now; //Save it to special collection for suspended sign-in processes TwoFactorSessions.insert({ hash: hash, code: newCode, username: username, sent: now }); // Wrap async task return Meteor.wrapAsync(function(user, hash, code, startTime, cb){ // Send code using Twilio to the phone number of user Twilio.messages.create({ to: user.phone, from: '+000000000000', body: 'Hi! Code - '+code }, function(error, message){ if (error){ // Return error with Twilio cb && cb(new Meteor.Error(500, 'Twilio error')); }else{ // Return 403, saying that SMS has been sent // hash, which user will send to us with code to identify his TF session cb && cb(null, [403, hash]); } }); })(user, hash, newCode, now); } } } });

ハッシュ引数を使用したメソッド呼び出しがクライアントから到着した場合、既存のオープン認証セッションを見つけようとする必要があります。これが存在する場合でも、その有効期間を確認する必要があります（クライアントは予測不能です。さまざまな引数を使用してコンソールからさまざまなメソッドを呼び出すキャラクターが必ず存在します）。すべてが正常な場合、クライアントに2番目の要素を通過する必要があることを理解させます。

ハッシュ引数がなく、最初の要素が渡された場合、コード（2番目の要素）、ハッシュを生成し、必要なものをすべて保存して、コード（2番目の要素）を提供します。ご覧のとおり、私のハッシュはまったくハッシュではなく、単なるタイムスタンプです。デモンストレーションには十分なように思えましたが、たとえば、開いているセッションをデバイスにバインドするためにデータを非表示にできる完全なハッシュを使用することを禁止する人はいません。

Twilioを使用するには、公式のtwilio-nodeモジュールを使用しました。 Node.jsからMeteorにモジュールを接続するには、便利なmeteorhacksパッケージnpmを使用できます。

Meteor.wrapAsyncにも注意を払う価値があります。 Meteorに精通している場合は、サーバー側のすべての非同期タスクをこの方法でラップする必要があることがわかります。

その結果、クライアントにハッシュが送信され、開いているセッションと、2番目の要素を入力するためのフォームを表示するコードがさらに識別されます。

すべてが非常に単純ですが、私は同意します、厄介です。

ステップ6〜7

次に、クライアント側について考えます。

認証-signInのテンプレートがあるとします。これには、最初の要素のフォームと2番目の要素のモーダルポップアップがあり、 ＃modalで識別され、すべてのネストされた要素は＃modal- <element name and role>として認識されます。覚えているように、開いているセッションを識別するためのハッシュはlocalstorage / cookieに保存する必要があるため、次のコードではStorageオブジェクトを使用します。これは何らかの抽象オブジェクトになり、それ自体が値を配置する場所を決定します（使用可能な場合、localstorageまたはcookie）。そして、ここにコードがあります：

 Template.signIn.events({ ... 'submit #signInForm': function(e) { e.preventDefault(); //Here go your methods for retreiving //username/email and password var username = ...; var password = ...; var pswdDigest = Package.sha.SHA256(password); // Check if there is previous Two-Factor session var sessionHash = Storage.get('two-factor-auth-hash'); if (sessionHash){ //Validate it maybe? //We have additional value here, code expiration time var valid = validateItHereAsYouWant(); if (!valid) sessionHash = null; } //Now actual login procedure start Meteor.call('LoginProcedure', username, pswdDigest, null, sessionHash, function(error, response){ if (error){ if (error.error === 400){ // That code would mean that session is invalid Storage.remove('two-factor-auth-hash'); // Show some alerts here } }else if (response[0]===200){ // That response code would mean that // two-factor authentication is turned off // and client received new login token immediately // right after passing simple username/password check Meteor.loginWithToken(response[1], function(err){ if(err){ alert('Problem!'); }else{ Router.go('Account'); } }); }else if (response[0]===403){ // That response code would mean that second factor code is sent // Open modal window with code input field $('#modal').modal(); // Save hash into storage for continuation Storage.set('two-factor-auth-hash', response[1]); // Show alert saying the code was sent }else if (response[0]===401){ // Open modal window with code input field $('#modal').modal(); // Show alert that there is previous code that awaits input } } ... 'click #modal-code-submit': function(e){ e.preventDefault(); // Read the code, get the id hash var code = $('#modal-code-input').val(); var hash = Storage.get('two-factor-auth-hash'); // Again get the values inside fields // i mean username and password ... // Throught the net, only the digest should go var pswdDigest = Package.sha.SHA256(pswd); // Perform login again, but with code and id hash Meteor.call('LoginProcedure', username, pswdDigest, code, hash, function(error, response){ if (error){ if (error.error === 400){ // That error code would mean that session is invalid Storage.remove('two-factor-auth-hash'); Storage.remove('two-factor-auth-ttl'); $('#modal').modal('toggle'); // Show some error alerts } }else if (response[0]===200){ // Seems like ok, login token received Storage.remove('two-factor-auth-hash'); // Login Meteor.loginWithToken(response[1]); } }); } });

コードにはコメントがたくさんあり、何が起こっているかを注意深く説明していますが、それでも説明します。

submit #signInFormイベントで、フォームの内容を読み取り、パスワードをハッシュし、Meteorメソッドを呼び出します。また、 ハッシュが見つかった場合は送信します。 4つの回答オプションのいずれかを受け取る予定です。

400-セッションは検証に合格しませんでした（ttlが期限切れです）。クライアントはハッシュを消去する必要があります。
200-最初の要素が渡され、2番目の要素がオンになっていないため、認証可能なトークンが到着しました。
403-新しいコード（2番目の要素）が生成および送信され、入力用のモーダルポップアップが表示されます。
401-古いコード（2番目の要因）はまだアクティブです。残りのセッションの有効期間と同じコードを入力する必要性を表示するポップアップを表示します。

モーダルウィンドウから、 click＃modal-code-submitイベントにより、同じMeteorメソッドを呼び出しますが、コード（2番目の要素）も渡します。その結果、次の2つの回答のいずれかを受け取ることを期待しています。

400-セッションはすでに有効期限が切れています。エラーを表示し、localstorage / cookieのハッシュをクリアします。
200-2番目の要素が正常に渡されました。エラーを回避するためにlocalstorage / cookieのハッシュを消去し、受信したトークンで認証します。

次に、サーバー側で2番目の要素チェックを実装する必要があります。このイベントは、Meteorメソッドが呼び出されたときに4つの引数すべてが存在することを特徴としています。そして、ここにコードがあります：

 Meteor.methods({ 'LoginProcedure': function(username, pswdDigest, code, hash){ //Steps 1-2 ... if (!user.twoFactorEnabled){ //Steps 1-2 ... }else{ if (code && hash){ //All 4 arguments present here //First factor has already been passed since we're here //Process second factor var session = TwoFactorSessions.findOne({ hash: hash, username: username }); if (session){ //Lets use some imaginary validation function //that you will define by your own in your project validateSession(session, user, code); // Passed all checks // Update two-factor session with submitted date TwoFactorSessions.update({ hash: hash }, { $set: { submitted: new Date() } }); // Generate and save login token using // previously defined function (look for it in steps 1-2) return saveLoginToken(user._id); }else{ // Couldnt find, return error throw new Meteor.Error(404, 'twoFactor.invalidHash'); } }else(hash){ //Step 3-5 ... }else{ //Step 3-5 ... } } } });

Meteorメソッドを呼び出すときの4つの引数は、開いているTFAセッションを終了しようとすることを意味します。最初に確認することは、そのようなセッションが存在するかどうかです。 MongoDBの単純なクエリ。

次に、セッションを検証します。少なくとも、以下を確認する必要があります。

このセッションがすでに閉じられているかどうか。
ttlの有効期限が切れていますか？
セッションを閉じるための試行回数を確認してください。
コードは一致しますか（2番目の要因）。
ユーザーとのセッションコンプライアンスの追加チェック。

検証が成功すると、セッションは閉じられたと見なされます。したがって、セッション終了時間を追加することにより、MongoDBのエントリを更新します。

次に、以前に定義された関数を使用してユーザーの新しいトークンを生成し、クライアント側に送り返します。

ステップ8

このステップのコードは最後のステップに含まれています。クライアント側では、トークンを受信すると、すぐにMeteor.loginWithTokenメソッドを呼び出して認証に成功します。

おわりに

多くのAPIにとって、Meteor.jsは、複雑で複雑な操作を行うことができないため、閉じられ、制限されているように見える場合があります。ただし、この記事で説明したように、標準パッケージには収まらないように見える機能をより深く見て実装できます。

もちろん、最も重要なことは、公式ドキュメントに記載されていない隠し関数を使用しなければならなかったことです。これらの機能は警告なしに変更される可能性があるため、多くの人が警告を受けます。しかし、それらがなければ、TFAを多かれ少なかれ通常の形式で実装することは困難です。少なくとも執筆時点では、単一の実装を見つけることができませんでした。

Meteor.jsの2要素認証