既存の認証を活かす
ID・パスワードをすぐに廃止できないサービスでも、所持確認を組み合わせた追加認証を検討できます。
DESIGNED FOR YOUR SERVICE
足したいのは、
確かめるためのワンステップ。
操作を指定して承認する
ログイン、配送先変更など、確認したい場面で承認待ちを作成。対象操作と会員を紐付けて検証します。
結果を本人にも知らせる
承認結果の返信に、サービス名と操作内容を記載。身に覚えのない操作への気付きにつなげます。
USER JOURNEY
利用者とシステムの、
具体的な動き。
STEP 01
既存認証・操作を開始
ID・パスワードで認証した後や、登録情報の変更前に承認待ち画面を表示します。
STEP 02
登録携帯から承認SMS
画面の承認番号を含むSMSを送ります。操作内容を利用者が確かめてから送信します。
STEP 03
登録番号と操作を照合
対象会員・承認対象の操作・有効期限をサーバー側で確認する構成にします。
STEP 04
承認結果を返して実行
承認結果を企業側が検証して操作を実行。SMSの返信で結果を利用者へ知らせます。
承認番号だけを、本人性の根拠にしません。
画面に出す短い承認番号は操作を識別するための表示例です。登録済み送信元番号、対象アカウント、対象操作、有効期限、試行回数をサーバー側で検証し、成功後は再利用できない設計にします。
DATA & INTEGRATION
既存の会員情報を、
照合の起点に。
構成図は連携方式を説明する参考イメージです。
正式なAPI仕様と責任分界は、導入時に確定します。
利用者の携帯利用者から
SMSを送信
SMSを送信
携帯通信網送信元番号を伴う
SMSの受信
SMSの受信
ATIRO CODE番号を照合し
認証コードを返信
認証コードを返信
企業側のAPI・会員DB既存データで会員を照合
認証結果を検証してセッション発行
認証結果を検証してセッション発行
企業側に残す：氏名・住所などの既存会員データ。Connect / Guardは会員DBの丸ごと移管を前提としません。
ATIRO側で扱う：SMSの送信元・宛先番号、SMS本文、照合用データなど。具体的な保存範囲・期間は契約時に確認します。
FIT & RESPONSIBILITY
導入前に、確認しておくこと。
向いている用途
既存ログインを維持する会員サイト、配送先や連絡先の変更、契約者向けポータルの追加確認など。
要件整理のポイント
パスワードとSMSを独立した認証要素として構成し、承認対象のデータ改ざん・別操作への流用・復旧経路の迂回を防ぐ設計が必要です。
SMS認証は、フィッシング耐性や公的な本人確認を保証するものではありません。SIM乗っ取り、番号変更・再割り当て、端末紛失、高リスク操作への追加認証を含めて設計します。
FAQ
Login Guardのよくある質問。
利用者にSMS送信料はかかりますか？
携帯3社の共同発表（2021年6月）では、共通番号宛のSMSは個人の送受信料が無料と案内されています。通常の携帯番号宛のSMS料金とは区別します。実際に採用する番号、対応回線、対象地域などの適用条件は、導入前に確認・案内します。
氏名や住所などの会員情報を預ける必要がありますか？
Login Connect / Guardは、提供資料では電話番号のハッシュ値を使って既存会員を照合する構成です。一方、SMSの受信・返信のために電話番号そのものの処理は発生します。Membersは会員基盤をATIRO側で提供するため、データを預かる範囲が異なります。
既存のパスワードログインと併用できますか？
併用や段階移行を前提に要件を整理できます。パスワードを残して登録携帯からの承認を加える場合はLogin Guardが選択肢です。旧ログイン・パスワード再設定・アカウント復旧が弱い入口として残らないよう、全体を設計します。
導入期間やAPIの仕様は決まっていますか？
接続先システム、会員データ、認証・復旧要件によって変わります。本サイトの連携図は導入を検討するための参考設計です。正式なAPI仕様、Webhookの有無、署名方式、契約条件は個別に確認します。
共通番号の個人向け料金に関する参考：携帯3社共同発表（2021年6月28日）。ATIROの採用番号・回線・地域などの条件は個別に確認します。