Azit Inc.

to Developer

DeliveryXで2段階認証の機能を開発しました!

  • #Webフロントエンド
  • #プロダクト
  • #開発

2025.05.26

Saito Ryosuke

こんにちは!
今年の2月に入社したばかり、Azit新人エンジニアの斉藤です!
(といっても新卒じゃなくて転職なので、他社でのエンジニア経験は10年くらいあります✌️)
AzitではDeliveryXのバックエンド開発とフロント開発の両方を担当してます。
普通の会社ならバックエンドならバックエンド、フロントならフロントだけと決められちゃいそうなところですが、ありがたいことに両方とも担当させて頂いてます。
自分は飽き性なので、色々と幅広い開発ができるのは嬉しい限りです。(感謝!)

はじめに

で、今回は何の話かというと!
AzitのメインプロダクトであるDeliveryXに2段階認証の機能を追加したのです!

\すごーい!/

というわけで今回の記事では、なぜ2段階認証の機能を開発したのか?や、開発するの中で工夫したポイントなどについて書いていこうと思います〜

2段階認証とは?

その前に、2段階認証とは?についても軽く説明しておきます。
(この記事を読んでる人は多分みんなリテラシー高いので知ってるとは思いますが、、念の為!)

2段階認証とは、「認証を2段階にすること」です!(そのまま過ぎますねw)
そもそも認証とは、「あなたは誰?」ってやつです。
一番よくあるパターンが、メールアドレスとパスワードを入力するアレですね。
あれで1認証となります。

ので、認証が2段階ということは「メールアドレスとパスワードだけじゃまだ本物か怪しい!もう一つ認証をクリアしてもらうぜ!」ってことなんです。

例えば事前に登録した合言葉を入力させたり、免許証を提示したり、指紋を確認したりとかです。
そうすることで「よし!お前さんが本物だと信じよう!」ってなるわけですね。
最近は不正ログインも話題ですし、セキュリティの重要性はますます高まってますよね。

Azitとしても「今どき2段階認証がないサービスはセキュリティ的によろしくないぞ!ユーザー様にも不安を与えちゃうぞ!良くない!」ってことで、今回2段階認証を開発することになったわけであります。
もちろん実際にユーザー様から「2段階認証欲しい!」という声も頂いてました。

設計について考える

2段階認証、なかなか大きい開発だと思うので新人エンジニアの自分には流石に担当回ってこないかな〜?と思いきや、なんと回ってきた!嬉しい!
いやーこれがスタートアップの良いところですわ。
最初から色々と大きい仕事がやりたいエンジニアの人!Azitおすすめですよ!(さりげなく宣伝)

で、上述したように2段階認証の方式にもいくつか種類がありまして。
どういう方式にするかユーザー様の意見も聞きながら検討した結果、最終的にはメールを使う方式にしました。
メールに認証コードを送信して、それをログイン時に入力してもらう方式です。
メールであれば既存ユーザーも必ず登録している情報でしたし、かなり一般的な方法なのでユーザーにとっても使いやすく、開発のコスパも良いだろうと。

1点悩んだポイントとしては、メールに認証コードを送信するのではなく、マジックリンクを送信して、マジックリンクを踏むことで自動的にログインする方式もアリだなと考えてました。
マジックリンク方式だと、認証コードを入力する手間を省けるんですね。
ただ、マジックリンク方式も悪くはなかったのですが、認証コードの方が一般的に広く受け入れられている概念なのでユーザー様が混乱しにくいかな、というところで最終的に認証コード方式を採用しました。

DeliveryXはエンプラサービスですし、あまりITに詳しくない人でもスムーズに使えることを優先した感じです。
これがITに詳しい人向けのサービス(Slackとか)だったらマジックリンク方式でもよかったかもしれませんね。

今後もサービスのペルソナを常に意識して「何が適切な設計なのか?」を考えていこうと思います。

いざ、開発

で、メールによる認証コード方式で開発することに決まったと。
ご存知の通り(?)DeliveryXはRuby on Railsで作られてるじゃないですか。
てことで何か良いgemはないかな〜と探したところ、以下の3つが候補になりました。

  1. devise-two-factor
  2. devise-otp
  3. rotp

まず1について

  • これはそもそも認証コードのためのライブラリではなく、Google AuthenticatorなどのOTPアプリのためのgem
  • 一応6桁の認証コードも生成できるが、それは内部的に3のrotpを利用しているだけ
  • 以下の記事にあるようにハマりポイントが多く、実質的にrotpを利用した場合とあまり変わらないことになりそう
  • あとDeviseログインを前提としており、DeliveryXではクライアントのログインはDeviseではなくhas_secure_passwordを利用しており、その変更も必要になる

2について

  • これも1と同様にGoogle AuthenticatorなどのOTPアプリのためのgem
  • 機能は豊富だが、今回の要件とは少しズレてるし過剰機能か

結論:3のrotpを利用することにしました

理由:今回はメール認証コードがあれば十分であり、今後もOTPアプリの機能を導入する予定もないため。仮に今後OTPアプリの機能を導入する場合でも、結局1と2は3をラップしてるだけなので、今回の開発が0からやり直しになることにはならない。

できた!

で、1週間ほどおりゃーと開発して、実際にできたのがこちら。

まずはログイン画面でOKボタンを押す

すると、通常はトップページに遷移するのですが、2段階認証を有効にしている場合はこんな風に認証コードを入力する画面になる

で、どれどれとメールボックスを見てみると、、ありました!
認証コード!

メールに記載されていた認証コードを入力して確認ボタンを押す!

無事にログインできました〜!(パチパチ👏)

おわりに

いやーなかなか良い感じじゃないでしょうか。
これでセキュリティレベルが1つ上がったサービスになりましたね!(やったー!)

今後さらにセキュリティを向上させるためには、IPアドレス制限や、認証アプリを用いた2要素認証の導入などが考えられそうです。
ただしセキュリティばかり向上しても肝心の中身の機能が不十分だと意味がないので、その辺りの開発の優先順位は難しいところですね。

Azitエンジニアとして、今後も引き続きDeliveryXをどんどんアップデートさせていきますので、よろしくお願いします!

現場からは以上です!


AzitではWebフロントエンドエンジニアを募集中です。ご興味をお持ちいただけましたら以下の採用サイトからご応募下さい!

この記事をシェアSHARE

この記事に関連する求人情報

  • Webフロントエンドエンジニア (Tech Lead)

この記事をシェアSHARE

MORE ARTICLES