Webシステムのログイン方式を選ぶとき、「安全だからパスキー」「簡単だからメール認証」「とりあえずGoogleログイン」と決めると、あとで運用に詰まることがあります。
認証方式は、利用者、扱う情報、利用頻度、端末、復旧方法、管理者の運用負荷で選びます。
この記事は、特定の方式を推すものではありません。BASIC認証、ID・パスワード、メール一時キー、外部ログイン、パスキー、認証プロキシ、APIキー、VPNなどを同じ地図の上に並べ、用途から選ぶための整理です。
まず用語を分ける
ログイン周りでは、似た言葉が混ざりがちです。
| 用語 | 意味 |
|---|---|
| 認証 | 誰であるかを確かめる |
| 認可 | その人が何をしてよいかを決める |
| 本人確認 | 現実の人物・会社とアカウントを結び付ける |
| セッション管理 | 認証後の状態を安全に維持する |
| 復旧 | 端末紛失やメール不達のときに本人へ戻す |
OAuthは本来、認可の仕組みです。ログインで使う場合は、OpenID Connectなどで認証情報を受け取ります。実務では「Googleログイン」「Microsoftログイン」と呼びますが、設計では認証、認可、本人確認を分けて考えます。
認証方式の比較
| 方式 | 向いている場面 | 主なメリット | 主な注意点 |
|---|---|---|---|
| BASIC認証 | 仮ページ、短期間のデモ | 構成が単純 | 利用者単位の停止、履歴、権限に弱い |
| ID・パスワード | 幅広い利用者を受け入れる | 自サービスだけで完結 | 漏えい対策、再設定、問い合わせ対応が必要 |
| パスワード + 二段階認証 | 既存パスワードを強化したい | 段階導入しやすい | 入力負荷、認証手段の管理が増える |
| メール確認コード | 低頻度利用、メール所有確認 | パスワード不要 | メール不達、転送、乗っ取り、試行回数制限 |
| マジックリンク | 低頻度利用で手間を減らす | クリックだけで入れる | リンク検査、別端末、転送、期限切れ |
| Google / Microsoft / Apple OIDC | 組織IDや一般IDを使う | パスワード管理を外部へ任せられる | 外部依存、個人用と組織用の混同 |
| GitHub / Xログイン | 対象者がそのサービスを使う | 登録が速い | 仕事上の本人性は別問題 |
| LINEログイン | スマートフォン中心の一般利用者 | 日本では使いやすい | LINEを使わない人への代替が必要 |
| Cloudflare Access等 | 管理画面、社内ツール | アプリ改修なしで入口保護しやすい | アプリ内権限とは別に設計が必要 |
| パスキー / WebAuthn | 継続利用する管理画面 | フィッシング耐性が高い | 初回登録、端末変更、復旧設計が必要 |
| APIキー / トークン | プログラム同士の接続 | 自動処理しやすい | 人間用ログインに流用しない |
| クライアント証明書 / VPN / 端末管理 | 高機密、限定端末 | 接続元を強く限定できる | 配布、更新、失効の運用が重い |
BASIC認証で十分な場面
BASIC認証は、短期間のデモ、仮ページ、検索エンジンに見せたくない準備中ページなどでは候補になります。
ただし、本格的な業務システムの利用者認証には向きません。共通IDを配ると、誰が見たか、誰を止めるか、退職者のアクセスをどう外すかが曖昧になります。
使うなら、配布範囲、終了日、パスワード変更手順を決めます。
メール一時キーが向く場面
メールで一時キーや確認コードを送る方式は、「そのメールアドレスを今読める」ことの確認で十分な場合に向きます。
たとえば、イベント申込、限定資料閲覧、申込内容確認、短期間の招待、メールアドレス確認などです。年に数回しか使わない利用者に、パスワードを覚えさせたくない場合にも使いやすいです。
一方、名刺情報、医療、金融、人事、重要な管理操作など、メールアカウントを奪われただけで全権を渡したくない用途では、それだけに依存しない方がよいです。
設計上は、次を守ります。
- コードやリンクは短時間で失効させる
- 一回使ったら無効にする
- 試行回数を制限する
- メール本文に長期利用できる固定キーを書かない
- リンク検査で先に消費される可能性を考える
- メール不達時の代替手段を用意する
外部IDを選ぶ基準
Google、Microsoft、AppleなどのOpenID Connectは、既に利用者が持つアカウントを使えます。特にMicrosoft Entra IDやGoogle Workspaceを使っている組織では、退職者停止や二要素認証を組織側の運用に寄せられることがあります。
ただし、外部IDは万能ではありません。個人用Googleアカウントなのか、会社管理のGoogle Workspaceなのかで意味が違います。メールアドレスは変わることがあります。ユーザー識別には、OIDCの sub のような安定した識別子を使う設計が必要です。
GitHubやXログインは、対象者がそのサービスを使う場合には便利です。しかし、仕事上の本人性や所属会社を保証するものではありません。
LINEログインは、スマートフォン中心の地域サービスや一般利用者向けでは有力です。一方で、LINEを使わない人への代替手段、業務上の本人・会社との結び付けを別に設計します。
パスキーで困る場面
パスキー / WebAuthn は、パスワードを保存せず、フィッシング耐性が高い方式です。管理画面や継続利用する業務システムでは強力な選択肢になります。
一方で、初回登録、端末変更、端末紛失、共有端末、同期されないパスキー、複数利用者の管理を設計しないと運用で困ります。
パスキーを使う場合でも、復旧用の予備手段が必要です。
- 複数パスキーの登録
- 管理者による再招待
- 組織IDとの併用
- 復旧時の本人確認
- 退職者の登録済み認証器の失効
セッション管理
認証後は、セッションを安全に維持します。
Cookieを使う場合は、少なくとも次を確認します。
Secure
HttpOnly
SameSite=Lax または Strict
__Host- プレフィックスセッションIDの生値をDBに保存せず、保存するならハッシュ化します。認証チャレンジや一時コードは短時間で失効させ、1回使ったら削除します。認証や重要操作では、OriginやCSRF対策も確認します。
APIキーはログインではない
APIキーやアクセストークンは、プログラム同士を接続するためのものです。人間のログイン用に流用しない方がよいです。
APIキーを使う場合は、用途ごとに発行し、権限を絞り、期限やローテーションを設け、漏えい時に止められるようにします。
用途別の選定指針
- 数日だけ見せる試作画面: BASIC認証も候補。ただし終了日を決める
- 少人数の社内管理画面: Cloudflare Access、Google/Microsoft OIDC、パスキーを比較する
- 不特定多数の一般向けサービス: 外部ログイン、メール確認、アカウント統合を検討する
- LINE利用が前提の地域サービス: LINEログインは有力。代替手段も用意する
- 年に数回しか使わない申込・閲覧: メール一時キーやマジックリンクが候補
- 毎日使う業務システム: 組織ID、パスキー、二要素認証を比較する
- 高機密システム: 組織ID + MFA、認証プロキシ、端末管理、監査ログを組み合わせる
- プログラム同士の接続: APIキーやアクセストークン。人間用ログインとは分ける
シオラボならどう選ぶか
最初に見るのは、技術の流行ではなく、利用者と運用です。
- 誰が使うのか
- 何を守るのか
- どの端末で使うのか
- 退職や異動をどう扱うのか
- 端末紛失やメール不達時にどう復旧するのか
- 管理者が続けられる運用か
認証方式は、安全なものを一つ選ぶ話ではありません。用途、情報の重さ、運用体制から組み合わせる設計です。