認証と認可・OAuthとは？「誰か」と「何をしてよいか」を分ける仕組み

2026-10-28 更新約9分で読めます

最終確認: 2026-10-27

30秒で復習

• 認証（Authentication）＝あなたは誰？を確かめる。 パスワード、MFA、パスキーなど。
• 認可（Authorization）＝あなたは何をしてよい？を決める。 権限、ロール、アクセスの範囲。
• OAuth（オーオース）2.0＝パスワードを渡さずに、アプリに「この範囲だけ使ってよい」という許可証（アクセストークン）を渡す仕組み。 本来は認可の仕組み。
• OpenID Connect（OIDC）＝OAuth の上に「誰がログインしたか」を伝える ID トークンを足したもの。 「Microsoft でログイン」「Google でログイン」の正体。
• トークンは3種類：ID トークン（誰か）・アクセストークン（APIを使う許可証、短命）・リフレッシュトークン（取り直し用、長め）。
• トークンは持っている人が使える。盗まれると、パスワードもMFAもなしで使われる（→MFAで防げない理由）。
• 覚え方：「フロントで身分証を確認（認証）、渡すのは自分の部屋だけ開くカードキー（認可）」

こんな場面で出会う

• 「Microsoft でサインイン」「Google でログイン」のボタンを押す
• アプリが「このアプリに予定表の読み取りを許可しますか？」と聞いてくる
• Web アプリで 401 と 403 のエラーの違いを聞かれる

用語の正式名称と読み方

用語	読み方・正式名称	意味
認証	AuthN（Authentication）	本人かどうかを確かめる
認可	AuthZ（Authorization）	何をしてよいかを決める
OAuth 2.0	オーオース	権限を委ねる（アクセストークンを渡す）ための標準の仕組み
OpenID Connect	オープンアイディーコネクト、OIDC	OAuth の上に、ログインした人の情報を伝える仕組みを足したもの
SAML	サムル	主に企業向けの SSO で使われる、XML ベースの古くからある仕組み
IdP	アイディーピー（Identity Provider）	本人確認とトークンの発行をするサービス。Entra ID、Okta、Google など
SSO	シングルサインオン	1回のログインで、複数のサービスを使えるようにすること
スコープ	scope	トークンで許す範囲。「メールを読むだけ」など
JWT	ジョット（JSON Web Token）	トークンのよくある形式。中身は署名つきの JSON
PKCE	ピクシー	認可コードを横取りされても使えないようにする仕組み

質問：認証と認可は何が違う？

答え： 認証は「あなたは誰？」、認可は「あなたは何をしてよい？」。順番は認証 → 認可で、別々に考える。

観点	認証（AuthN）	認可（AuthZ）
問い	あなたは誰？	何をしてよい？
例	パスワード、MFA、パスキー、証明書	「経理部だけ経費システムOK」、管理者ロール、ファイルのアクセス権
失敗したとき	401（誰か分からない）	403（誰かは分かったが、権限がない）
関係するノート	MFAとは、証明書	ZTNAのルール、SASEの条件による制御

イメージ（たとえ話）

• 認証＝ホテルのフロントで身分証を見せる。 予約した本人だと確かめる。
• 認可＝渡されたカードキーで開く部屋が決まっている。 本人であっても、他人の部屋は開かない。
• OAuth＝本人がフロントに「このクリーニング業者に、私の部屋のクローゼットだけ開けさせて」と頼み、業者専用の期限付きカードキーを作ってもらう。 業者に自分のカードキー（パスワード）は渡さない。

質問：OAuthとは？ なぜパスワードを渡さないのか

答え： 昔は、あるアプリに別のサービスのデータを使わせるとき、そのサービスのパスワードをアプリに預けていた。これだと、アプリは何でもできてしまい、パスワードを変えるまで止められない。OAuth では、パスワードの代わりに範囲と期限が限られた許可証（アクセストークン）を渡す。

観点	パスワードを預ける（昔）	OAuth
アプリが知るもの	パスワードそのもの	期限付きの許可証（パスワードは知らない）
できること	本人と同じ、何でも	許可した範囲だけ（スコープ）
やめさせたいとき	パスワードを変える（ほかのアプリも全部止まる）	そのアプリの許可だけ取り消せる
MFA	アプリ経由のログインでは効かないことが多い	ログインは IdP の画面でするので、MFAが効く

いちばんよく使う流れ：認可コードフロー（＋PKCE）

1. 利用者がアプリで「Microsoft でログイン」を押すと、ブラウザが IdP（Entra ID など）のログイン画面に移る
2. 利用者は IdP の画面でパスワードと MFA を入れる（アプリはパスワードを見ない）
3. 「このアプリに、メールを読むことを許可しますか？」の同意をする
4. IdP は、使い捨ての認可コードをアプリに返す
5. アプリは、認可コード（と PKCE の合言葉）を IdP に送り、トークンと交換する

6. アプリはアクセストークンを付けて API を呼ぶ。API はトークンの署名・期限・範囲を確かめる

7. PKCE：アプリが最初に「合言葉の答え」を隠し持っておき、⑤で答え合わせをする。途中で認可コードを横取りされても、合言葉を知らない攻撃者は交換できない。今はスマホアプリでも Webアプリでも使うのが基本。

8. アプリ同士（人がいないバッチなど）では、クライアントクレデンシャルという流れで、アプリ自身の秘密や証明書でトークンをもらう。

質問：トークンにはどんな種類がある？

トークン	誰のためのもの？	中身・役割	有効期限の目安
ID トークン	アプリ	誰がログインしたか（名前・メール・ID）。OIDC で使う	短い
アクセストークン	API	何をしてよいか（スコープ・ロール）。API を呼ぶときに付ける	短い（1時間前後が多い）
リフレッシュトークン	IdP	アクセストークンを取り直すための券。ログインし直さずに済む	長い（日〜数十日）。いちばん大事に守る

• アクセストークンは「持っている人が使える」（ベアラートークン）。盗まれると、その期限の間は本人になりすまされる。
• ブラウザでは、ログイン後にセッション Cookieが使われる。これも同じく、盗まれるとログイン済みとして扱われる（→AiTMフィッシング）。

質問：OAuth・OIDC・SAMLはどう使い分ける？

仕組み	主な目的	よく使う場面
OAuth 2.0	アプリに API を使う許可を渡す（認可）	「このアプリに予定表を読ませる」、API 同士の連携、MCPのリモートサーバーの認可
OpenID Connect	ログイン（認証）と SSO	「Microsoft・Google でログイン」、新しく作る Web・スマホアプリ
SAML 2.0	企業向けの SSO（認証）	古くからある業務 SaaS への SSO

迷ったら、ログインは OIDC、API の許可は OAuth。SAML は、相手のサービスが SAML にしか対応していないときに使う。

質問：OAuthで気をつけることは？（攻撃者の視点も）

注意点	起きること	対策
同意フィッシング（不正な同意）	攻撃者の作ったアプリが「メールを読む許可をください」と本物の Microsoft の画面で同意を求める。同意すると、パスワードもMFAも関係なくメールを読まれ続ける	利用者が勝手に同意できる範囲を絞り、管理者の承認を必須にする。同意済みのアプリを定期的に棚卸しする
トークンの盗難	PCに入ったマルウェアや AiTM で、トークンや Cookie を盗まれる	トークンの期限を短く、怪しいサインインで即座に無効化（継続的アクセス評価）、トークンを端末に結び付ける仕組み
広すぎるスコープ	読むだけでよいのに「全部の権限」を許してしまう	アプリが求めるスコープを最小限にする
デバイスコードの悪用	「このコードを入力してログインして」と攻撃者に頼まれ、本物の画面で入力すると、攻撃者の端末がログインできてしまう	使わないならデバイスコードフローを条件付きアクセスで止める
リダイレクト先の設定ミス	認可コードやトークンが、攻撃者のサイトへ送られる	リダイレクト URI は完全一致で登録する。PKCE を使う

関連メモ

• 多要素認証（MFA）とは？ なぜ普通のMFAでは防げないのか
• SASEの認証と、端末・ネットワークによる制御
• プロキシとリバースプロキシ（AiTMフィッシング）
• MCP（Model Context Protocol）とは？

確認したいこと

• 利用者が、勝手にアプリへ同意できる設定になっていないか（管理者の承認が必要か）
• 同意済みのアプリと、そのスコープの一覧を見たことがあるか
• デバイスコードフローやレガシー認証（MFAが効かない古い方式）は止めているか
• 社内で作るアプリは、認可コードフロー＋PKCE を使っているか

参考資料

• OAuth 2.0 認可フレームワーク（RFC 6749）
• PKCE（RFC 7636）
• Microsoft ID プラットフォームの OAuth 2.0 と OpenID Connect（Microsoft Learn）