はじめに
目的
本書は、WebサイトやWebアプリで使われる「認証」について、仕組みや分類、セキュリティの観点から分かりやすく説明することを目的としています。技術に詳しくない方でも理解できるよう、具体例を交えて解説します。
対象読者
- Webサービスの運営者や開発者
- 認証の基礎を学びたいエンジニアや管理者
- セキュリティに関心のある一般の方
範囲と進め方
まず認証の基本概念を示し、主要な方式の特徴と課題を順に説明します。各章で実例やメリット・デメリットを挙げるため、実務での判断に役立ちます。例えば、ログイン画面におけるIDとパスワードや、スマホアプリがAPIへアクセスする際のトークン利用などを取り上げます。
読み方のヒント
すぐ使えるポイントを知りたい場合は、各章のメリット・デメリット部分を先に読んでください。技術的な仕組みを深く知りたい場合は、第3〜6章を順に読むことをおすすめします。
Webサービスの認証の種類と特徴
はじめに
Webサービスの認証は大きく三つに分かれます。ここでは種類ごとに分かりやすく説明します。
1. 相手認証（通信相手の確認）
相手認証は、接続してきた相手が正しいかを確かめます。例としては、ログインしているユーザーを識別する仕組みです。もっとも一般的な用途で、Webサイトではこの方式が広く使われます。
2. メッセージ認証（改ざん検出）
メッセージ認証は、送受信するデータが途中で改ざんされていないかを確認します。たとえば、通信内容に署名を付けて受け取った側でチェックします。これによりデータの整合性を守れます。
3. ディジタル認証（文書や本人の保証）
ディジタル認証は、文書や送信者の正当性を保証します。電子署名のように、誰が作成したかを証明し、否認防止に役立ちます。
Webでよく使われる相手認証の種類
Webサイトでは相手認証の中でも「セッション認証」と「トークン認証」が多く使われます。
-
セッション認証：サーバーがセッションIDを発行し、ブラウザのcookieで管理します。ログイン後はサーバー側でユーザー情報を保持するため、ログアウトや権限管理が比較的容易です。一方でサーバーの負荷やスケール対応、CSRFなどに注意が必要です。
-
トークン認証：APIやモバイルアプリで多用されます。サーバーは署名付きのトークンを発行し、クライアントはHTTPヘッダなどで送ります。状態をサーバーに保持しないことが多く、スケールしやすい利点があります。反面、トークンが盗まれると悪用されやすく、有効期限や失効の扱いに工夫が必要です。
実際のサービス設計では、用途に応じてこれらを組み合わせて使うことが多いです。例えば、ウェブの管理画面はセッション認証、公開APIはトークン認証にする、といった使い分けがよく見られます。
主なWeb認証方式の種類とセキュリティ特徴
知識認証（パスワード・PIN）
パスワードやPINは最も一般的です。覚えやすさが利点ですが、推測・使い回し・漏洩のリスクがあります。対策としては長く複雑なパスワードやパスワードマネージャー、サーバー側でのハッシュ化（ソルト付き）やログイン試行制限が有効です。
所有物認証（トークン・証明書）
ハードウェアトークン（例：YubiKey）やソフトウェアトークン（認証アプリ）、クライアント証明書が該当します。物理キーはフィッシングに強く、安全性が高いです。一方、紛失や盗難が課題なのでバックアップ手段や失効手続きが重要です。
生体認証（指紋・顔認証など）
指紋や顔認証は利便性が高く、端末上での認証が一般的です。生体情報自体はサーバーで丸ごと保存せずテンプレート化して保管します。偽造やプライバシーの懸念があるため、端末内の保護（安全な要素）と併用することを推奨します。
二段階認証（2FA）とFIDO/WebAuthn
2FAはID+パスワードに加え別の要素を使います。SMSは手軽ですがSIMスワップで危険です。TOTP（認証アプリ）はより安全でオフラインでも使えます。FIDO/WebAuthnは公開鍵暗号を使い、秘密鍵を端末に保持するためフィッシングに非常に強いです。一般的には、重要なサービスほど所有物認証やFIDOの利用を検討するとよいでしょう。
認証方式の種類一覧とメリット・デメリット
ベーシック認証
- 概要: ブラウザがIDとパスワードを毎回送る仕組み。例: 簡易な管理画面。
- メリット: 実装が簡単で設定も少ない。
- デメリット: 平文や簡易な暗号で送られると危険。長期運用や公開サービスには不向き。
Digest認証
- 概要: パスワードをそのまま送らずハッシュでやり取りする方式。
- メリット: 平文送信を避けられる。
- デメリット: 実装が古く対応が限定的。
セッションベース認証
- 概要: サーバー側でセッションを保持しクッキーで識別する。例: 伝統的なWebアプリ。
- メリット: ログアウトやセッション管理がしやすい。
- デメリット: サーバー負荷やスケール時の工夫が必要。CSRF対策も重要。
トークンベース（例: JWT）
- 概要: サーバーが発行したトークンをクライアントが保持して送る。APIに多い。
- メリット: スケーラブルで分散環境に向く。
- デメリット: トークンの失効や長期有効化の管理が難しい。
ワンタイムパスワード（OTP）
- 概要: 使い切りのコードを使う。例: 銀行の二段階認証。
- メリット: フィッシングやリプレイ攻撃に強い。
- デメリット: 発行や配布の手間、ユーザー負荷。
OAuth / OpenID
- 概要: 第三者のIDでログインや権限委譲を行う仕組み。例: Googleログイン。
- メリット: ユーザーの利便性向上とパスワード管理不要。
- デメリット: 実装が複雑で設定ミスがリスクになる。
SSO と SAML
- 概要: SSOは一度の認証で複数サービスへアクセスする考え方。SAMLはその実現技術の一つ。
- メリット: 利便性と集中管理で運用が楽になる。
- デメリット: 中央の認証基盤が破られると影響が大きい。
Basic認証の仕組みと課題
概要
Basic認証はHTTPで簡単に使える方式です。ブラウザやクライアントが「ユーザー名:パスワード」をBase64で変換して、Authorizationヘッダに載せて送ります。Base64は暗号化ではなく変換なので、盗聴されると簡単に復元されます。
動作の流れ
- クライアントが保護領域にアクセスするとサーバーが401応答とrealmを返します。
- クライアントが資格情報を入力し、Authorization: Basic {Base64文字列}を送信します。
- サーバーが復号（デコード）して照合し、合致すればアクセスを許可します。
主な課題
- 通信が暗号化されていないと盗聴でID/PWが漏れる。
- 資格情報が毎リクエスト送られるため露出面が広い。
- ブラウザに認証情報が保持され、ログアウトが困難。
- リプレイ攻撃やプロキシでの保存リスクがある。
対策と代替手段
- 常にHTTPSで運用することが最優先です。
- 重要なサービスではフォーム認証＋セッションやトークン方式に置き換えてください。Digest認証やOAuthなどの方式も検討してください。
- 短期間でパスワードを変更する、IP制限やVPNと併用する、HTTPヘッダでキャッシュ禁止を設定するなどの対策を行ってください。
設定のポイント
- サーバー設定でアクセス制限やログ出力を確認する。
- .htpasswdなどで強いパスワードを管理する。
- 公開APIにはBasicを直接使わず、限定的な用途に留めると安全性が向上します。
認証と認可の違いとOAuthの役割
認証と認可の違い
認証は「あなたは誰ですか？」を確かめる作業です。例えばログインでIDとパスワードを入力するのが認証です。認可は「何ができますか？」を決める作業です。ログイン後に閲覧や編集などの権限を与えるのが認可です。
OAuthの基本的な役割
OAuthは認可のための仕組みです。第三者アプリがユーザーの代わりに特定の操作を行う許可を得るために使います。ログインそのものを保証するプロトコルではありませんが、アクセスの委譲に便利です。
OAuthのしくみ（簡単な流れ）
- ユーザーが第三者アプリからアクセスを要求します。
- サービス提供者である認可サーバーがユーザーに同意を求めます。
- 同意後、認可サーバーは第三者に一時的な「トークン」を発行します。
- 第三者はそのトークンで限定された操作を行います。
トークンには有効期限や範囲（スコープ）を設定します。
利用例と注意点
例：写真アプリがあなたのクラウド写真を読み込む場合、クラウドにパスワードを渡さずアクセス権だけ与えます。注意点はトークンの管理やリダイレクト先の正当性、通信の暗号化です。OpenID Connectを組み合わせると、認証（ログイン）機能も安全に実現できます。
最新の認証動向と多要素認証の重要性
概要
近年はパスワードだけに頼らない仕組みが広がっています。スマホの指紋や顔認証、ワンタイムパスワード（OTP）、セキュリティキーが代表例です。利便性と安全性を両立するため、多要素認証（MFA）の導入が進んでいます。
多要素認証とは
多要素認証は「知識」「所有」「生体」のうち複数の要素を組み合わせます。たとえばパスワード（知識）とスマホの確認コード（所有）を同時に使うと攻撃に強くなります。実例を挙げると、ネットバンキングでパスワードに加えSMSコードを要求する方式です。
FIDOと二段階認証（2FA）
FIDOはパスワードを使わない方式で、端末の鍵と生体認証を組み合わせます。キーを挿すだけでログインできる場合もあり、フィッシングに強い特長があります。2FAは手軽で多くのサービスが採用しています。
生体認証と注意点
生体認証は便利ですが、データ漏えいや偽造リスクに注意が必要です。生体情報は一度盗まれると変更できないため、端末側で安全に保管する設計が重要です。
OAuth・SSOの利便性
OAuthやシングルサインオン（SSO）は利便性を大きく高めます。1回の認証で複数サービスを利用できる反面、一本化された認証情報が狙われやすくなる点に注意してください。
導入時のポイント
ユーザーの使いやすさを最優先にしつつ、リスクに応じて要素を選びます。管理側はログ監視や段階的な導入、ユーザー教育を行うと効果的です。
