「認証と認可 — 一枚の地図」のタイトルバナー。ティールのノード線で結ばれた経路上に、金色の鍵アイコン(誰か=認証)と門のアイコン(何をしてよいか=認可)を配したモチーフ。

この記事の要点

  1. 認証(authn)と認可(authz)は別ものです。「本人確認(誰か)」と「権限(何をしてよいか)」を分けて考えるのが出発点になります。
  2. 対象読者: 企業の実務で AI・クラウドのアカウント管理に関わる方、個人で開発する方。認証まわりを「製品名」でなく「役割」で整理したい人向けで、前提知識は不要です。
  3. 得られる成果: パスワード → 多要素認証 → パスキー → シングルサインオン → OAuth / OIDC / SAML → ゼロトラスト を一枚の地図でつなぎ、それぞれが「どこで何の役割か」を説明できるようになります。
  4. 扱わないこと: 製品ごとの設定手順・移行テンプレート・実装コードは扱いません(各サービスの公式ドキュメント・設定画面の領域です)。本記事は「読んで仕組みが分かる」ことに絞ります。

Key Points (for international readers)

  1. Authentication (who you are) and authorization (what you may do) are different. Telling them apart is where identity makes sense.
  2. The method travels: read identity by role — password → MFA → passkeys → SSO → OAuth / OIDC / SAML → Zero Trust — as one connected map, not as isolated products.
  3. Building for the US or EU? The English edition centers on US/EU frameworks — NIST SP 800-63-4 (assurance levels) and eIDAS 2.0 / the EU Digital Identity Wallet — as a companion piece, not a translation.
  4. Out of scope: product-specific setup steps, migration templates, and implementation code. This piece is the concept map only.

執筆時点: 2026-06 / 対象法域: 日本国内法(不正アクセス禁止法の文脈)。米国・EU は英語版で主軸として扱います / last_updated: 2026-06-16

本記事は教材であり、法的助言ではない

本記事は認証・認可の仕組みを概念として整理する 教育目的の一般的な解説 です。特定の製品・構成・契約条項に対する技術的・法的助言ではなく、内容の正確性・完全性・最新性を保証しません。標準(NIST SP 800-63 など)や各社の仕様・既定値は予告なく改定されます。本記事の記述は 2026 年 6 月時点で確認できた範囲 であり、実際の設計・導入の判断は必ず 最新の公式ドキュメント + 必要に応じて専門家(セキュリティ・社内情報システム・弁護士)にご確認ください。法令(不正アクセス禁止法など)に触れる箇所は「概念として理解するための文脈」であり、適法・違法の判断や個別事案への助言ではありません。本記事の情報は「現状有姿(AS IS)」で提供され、利用または信頼した結果生じたいかなる損害についても、執筆者および YATA-NODE は一切の責任を負いません。

本シリーズの位置づけ: セキュリティの基礎を扱う記事群の一つです。企業ネットワークの仕組み で境界とゼロトラストの考え方、通信セキュリティの全体像 で通信の守り、VM・コンテナ・サンドボックスの隔離入門 で実行環境の隔離を扱いました。本記事はその中で「誰がアクセスしてよいかを確かめる仕組み(認証と認可)」を地図にする回です。

用語ミニ解説(はじめての方へ):

  • 認証(authn = authentication): 相手が「誰か」を確かめること(本人確認)。パスワードや指紋などで行います。
  • 認可(authz = authorization): 確かめた相手が「何をしてよいか」を決めること(権限)。
  • 多要素認証(MFA = Multi-Factor Authentication): パスワードに加えて、別の要素(スマホの確認・指紋など)を組み合わせる認証。
  • パスキー(passkey)/ FIDO2 / WebAuthn: パスワードの代わりに、端末内の秘密鍵で本人確認するパスワードレスの仕組み。FIDO2・WebAuthn はその技術仕様です。
  • シングルサインオン(SSO = Single Sign-On): 一度の認証で複数のサービスにログインできる仕組み。
  • OAuth / OIDC / SAML: サービス間で「認可」や「認証」を受け渡すための取り決め(プロトコル)。後述します。
  • ゼロトラスト(Zero Trust): 「社内ネットワークだから安全」と仮定せず、リソースやセッションごとに、状況やリスクに応じて本人と権限を確かめ直す考え方。

「ログインできた=安全」と感じやすいですが、ログインの裏側では「本人か(認証)」と「何をしてよいか(認可)」が別々に動いています。さらにパスワードからパスキーへ、単独のサービスから複数サービス連携(SSO)へと、認証の形は層になって広がってきました。本記事は、その全体を一枚の地図としてつなぎ、最後に「自分の立場で何を確かめるか」を整理します。製品の選び方や設定手順ではなく、どの技術が地図のどこにあるかを理解することがゴールです。

認証と認可の全体像を一枚にまとめた概念図。上部に「認証=誰か」「認可=何をしてよいか」、下に2レーン=「本人確認を強くする」(パスワード→多要素認証→パスキー)と「認証・認可を安全に受け渡す」(シングルサインオン→OAuth/OIDC/SAML)を配し、全体をゼロトラストの枠が囲む。

認証と認可の違い — 「誰か」と「何をしてよいか」を分ける

最初の分かれ道が、認証(authn)と認可(authz)の区別です。認証は「相手が誰かを確かめること」、認可は「確かめた相手が何をしてよいかを決めること」です。順番も決まっていて、まず認証があり、その結果を使って認可が判断されます。

オフィスの入館にたとえると分かりやすくなります。入口で社員証をかざして本人だと確認するのが認証です。そのうえで「この人は 3 階の開発フロアには入れるが、サーバ室には入れない」と決めるのが認可です。同じ「入れる/入れない」でも、本人確認と権限判断は別の仕組みが担っています。

この区別が大切なのは、片方だけでは守れないからです。認証が完璧でも、認可の設計が甘ければ、ログインした利用者が本来見えないはずのデータに手が届いてしまいます。逆に認可が厳密でも、認証が破られて他人になりすまされれば意味がありません。以降に出てくるパスキーや OAuth といった技術も、突き詰めれば「認証を強くする話」か「認可を安全に受け渡す話」のどちらか、あるいは両方に位置づけられます。これが地図全体の起点です。

パスワードからパスキーへ — 認証強度の進化と多要素認証

認証の歴史は、おおまかに「パスワードを強くする」方向と「パスワードに頼らない」方向に進んできました。

出発点はパスワードです。手軽ですが、使い回しや漏えい、フィッシング(偽サイトに入力させる手口)に弱いという弱点があります。そこで加わったのが多要素認証(MFA)です。パスワード(知っている要素)に、スマホへの確認や指紋(持っている要素・本人の要素)を組み合わせ、片方が漏れても突破されにくくします。ただし MFA にも強弱があり、(Short Message Service。携帯電話番号宛に届く短い文字メッセージ)で送る確認コードは、番号の乗っ取りや偽サイト経由の中継に弱いことが知られています。アプリで生成する確認コード(TOTP)はそれより堅く、さらに堅いのがパスキーです。

パスキー(技術仕様としては FIDO2 / WebAuthn)は、パスワードそのものを使わない仕組みです。端末の中に秘密鍵を保管し、サービス側には公開鍵だけを預けます。ログイン時は端末内の秘密鍵で署名するだけなので、サーバから盗めるパスワードが存在せず、偽サイトに誘導されても本物のサービス以外には反応しません。フィッシングに強いのが大きな利点です。

米国連邦政府の標準である NIST SP 800-63 では、認証の強さを「保証レベル(AAL)」という段階で整理しています。パスキーは耐フィッシング性が高い認証方式ですが、保証レベル上の位置づけは実装形態(要素の数や鍵の保護方法など)によって決まります。詳しい各国の枠組みは英語版で扱いますが、ここでは「パスワード → 多要素 → パスキー」と進むほど、なりすましに強くなると押さえておけば十分です。

シングルサインオンとプロトコル — OAuth・OIDC・SAML を「役割」で整理する

サービスが増えるほど、それぞれに別々のパスワードを持つのは現実的でなくなります。そこで登場するのがシングルサインオン(SSO)です。一度どこかで本人確認すれば、つながった複数のサービスに改めてログインせずに入れる仕組みで、社内システムや業務用クラウドでよく使われます。

この SSO を裏で支えるのが、OAuth・OIDC・SAML というプロトコル(取り決め)です。混同されがちですが、それぞれ担う役割が違います。

3つのプロトコルの役割を並べた図。OAuth 2.0=認可の委譲(ログインではない)、OIDC=OAuth+認証(ID token)、SAML=企業SSO(XML でやり取り)。下に「OAuth 単体は認証ではない」の注記。
  • OAuth 2.0 は「認可の受け渡し」を担います。たとえば「あるアプリに、自分のカレンダーへのアクセスを許可する」ように、パスワードを渡さずに権限の一部だけを別のサービスへ委譲する仕組みです。OAuth 自体は「誰か」を確かめる認証の仕組みではない、という点がよく誤解されます。
  • OIDC(OpenID Connect) は、その OAuth の上に「認証」を載せたものです。「このアクセスを許可した利用者は確かに本人だ」という情報(ID トークン)を受け取れるようにし、「○○アカウントでログイン」のような体験を実現します。
  • SAML は、主に企業の SSO で長く使われてきた仕組みで、XML という形式で本人確認の情報をやり取りします。役割は OIDC と近いのですが、社内システムや業務用クラウドの連携でよく見かけます。

「どれを選ぶか」は設計時の話なので本記事では踏み込みません。ここでは「OAuth は権限の委譲、OIDC は OAuth に認証を足したもの、SAML は企業 SSO の定番」と、役割で覚えておけば地図の上で迷いません。なお、ログイン後に「ログインした状態」を保つ仕組みには、サーバが覚えておくセッションと、利用者側が持ち歩くトークンの二通りがあります。OAuth や OIDC でやり取りされるのは後者のトークンだと押さえておくと、つながりが見えやすくなります。

ゼロトラストと ID 中心化 — なぜ「誰か」が新しい境界になったのか

かつてのセキュリティは「社内ネットワークの中は安全、外は危険」という境界の考え方が中心でした。しかし、クラウドの利用や在宅勤務が当たり前になると、「中か外か」だけでは守れなくなります。社外から正規のアカウントでアクセスする働き方が普通になったからです。

そこで広まったのがゼロトラストです。「ネットワークのどこにいるか」で信頼するのをやめ、リソースやセッションごとに、状況やリスクに応じて「誰か(認証)」と「何をしてよいか(認可)」を確かめ直す考え方です。この発想では、守りの中心がネットワークの場所から ID(本人の識別情報)へと移ります。「ID が新しい境界になった」と言われるのはこのためです。

ここまでの地図がそのまま効いてきます。リソースごとに本人を確かめ直すなら、認証は強いほどよく(だからパスキー)、複数サービスで一貫して確かめるなら連携の仕組みが要る(だから SSO とプロトコル)、というように、これまでの各層がゼロトラストの下で一つにつながります。

日本での法的文脈 — 認証はどこで法律とつながるか

最後に、認証が法律とつながる場面を概念として触れておきます。ここは適法・違法を判断する話ではなく、「なぜ認証を軽く扱えないのか」を理解するための文脈として読んでください。

日本には不正アクセス禁止法(不正アクセス行為の禁止等に関する法律)があります。この法律は、他人の識別符号(ID やパスワードなど、本人を識別するための符号)を定義したうえで、それを用いた不正アクセス行為などを禁止・規律しています。言い換えると、認証の仕組みが破られて他人になりすまされる事態は、技術的な事故であると同時に、法律が線を引いている領域に接続しうる、ということです。

ここから言えるのは、認証は単なる利便性の設定ではなく、漏えいやなりすましが起きたときに法的な問題へ波及しうる土台だ、という見方です。具体的にどの行為がどう扱われるか、自社のケースが該当するかどうかは、必ず最新の条文と専門家(弁護士・社内法務)にご確認ください。本記事はあくまで「認証が法律と接する地点がある」という地図上の位置づけを示すに留めます。

まとめ

認証と認可は、「誰か」と「何をしてよいか」という別々の問いです。この出発点から見ると、パスワード・多要素認証・パスキーは認証を強くする話、SSO と OAuth / OIDC / SAML は認証や認可を安全に受け渡す話、ゼロトラストはそれらを「リソースごとに状況に応じて確かめ直す」考え方として束ねるもの、と一枚の地図に収まります。製品や用語の多さに圧倒されたときは、「これは認証の話か、認可の話か」「地図のどこに置けるか」と問い直すと、選定や設計の前提が整理できます。

仕組みが分かったら、実際の設定や運用は各サービスの公式ドキュメントが頼りになります。本記事の関連として、主要 AI サービスのセキュリティ設定 では個別サービスでの認証設定の考え方、社内アプリを内製する前に では自分で作るアプリに認証・認可をどう組み込むかの前提を扱っています。あわせて読むと、地図が実地につながります。

References