認証と認可の違いとは?OAuth・多要素認証をやさしく解説

認証と認可の違いとは?OAuth・多要素認証をやさしく解説

認証と認可の違いに悩むIT初心者
「認証と認可って、何が違うの?」
「多要素認証って、なぜ必要なの?」
「OAuth とか OIDC って、結局なに?」

そんな疑問を抱える、基本情報技術者を目指すあなたへ。

結論から言えば、認証は「あなたが誰か」を確かめる仕組み、
認可は「何をしてよいか」を決める仕組み

で、MFA や OAuth はその信頼性を高めるための基盤です。

この記事では、認証と認可の違い、多要素認証(MFA)の3要素、OAuth 2.0 と OpenID Connect の基本までを、初心者向けにやさしく整理します。

 

1. 認証(Authentication)とは

1. 認証(Authentication)とは

認証とは、システムを使おうとしている人が「本当にその本人なのか」を確かめるプロセスのことです。英語では Authentication と呼ばれます。

身近な例で言えば、会員制ジムに入るときの「会員証提示」が認証にあたります。「会員本人である」ことを確認する手続きが、システム上のログインに相当します。

 

会員制ジムでは「会員証の提示」が認証、「フリーウェイトエリアに入れるか」が認可、と役割が分かれます。同じ仕組みが業務システムにも当てはまります。

 

もっとも基本的な認証方法は、ID とパスワードの組み合わせです。入力された ID とパスワードが登録済みのものと一致すれば本人と判定するシンプルな仕組みです。

ただし、この方法には弱点があります。パスワードが漏洩したり使い回されると、第三者にログインを突破される可能性があるためです。

そこで近年は、多要素認証(MFA)を組み合わせる方法が一般的になってきました。パスワード自体はハッシュ化や暗号化を併用して保管されます。

 

2. 認可(Authorization)とは

2. 認可(Authorization)とは

認可とは、認証された人が「何をしてよいか」を決めるプロセスのことです。英語では Authorization と呼ばれます。あなたが認証を通った後、システム上で実行できる操作範囲を決めるのが認可の役割です。

先ほどのジムのたとえで言えば、会員証提示が認証、入場できるエリアの違いが認可にあたります。一般会員は通常エリアまで、プレミアム会員はサウナまで、というエリア分けがシステム上の「権限」に相当します。

 

企業の業務システムでは、認可の設計に RBAC(ロールベースアクセス制御)という考え方が広く使われています。役職や役割ごとに権限をまとめて管理し、ユーザーをロールに割り当てる方式です。

もう一つ重要な設計指針が 最小権限の原則です。利用者には業務遂行に必要な最小限の権限だけを与える、という方針を指します。余分な権限を付与しないことで、アカウント侵害時の被害範囲を抑えやすくなります。

 

認可設計の2大キーワード
・RBAC:役割ごとに権限をまとめて管理
・最小権限の原則:必要最小限だけを付与

 

大切なのは、認証と認可は別物だという点です。両者を混同すると「ログインできた=何でもできる」という設計ミスにつながります。本人確認と権限付与は、設計上はっきり分けて考えるのが基本です。

 

3. 多要素認証(MFA)と生体認証

3. 多要素認証(MFA)と生体認証

多要素認証(MFA: Multi-Factor Authentication)とは、認証3要素のうち2つ以上を組み合わせる仕組みです。日常的に使っている「ID/パスワード+スマホ通知」型のログインも、MFA の一種にあたります。

マンションのたとえで言えば、鍵(所持要素)と暗証番号(知識要素)の両方が揃わないと部屋に入れない仕組み、と考えるとイメージしやすいです。

 

認証の3要素
・知識要素:パスワード・PIN・秘密の質問
・所持要素:スマホ・ICカード・ハードウェアトークン
・生体要素:指紋・顔・虹彩

 

このうち、生体要素を使う認証を生体認証(バイオメトリクス認証)と呼びます。指紋認証や顔認証が代表例で、スマホのロック解除でも広く使われています。

生体認証は単独でも使われますが、業務システムでは知識要素や所持要素と組み合わせて使うのが一般的です。生体情報は変更が難しいため、漏洩時の影響を考えて慎重に設計されています。

 

MFA を導入すると、パスワード単独運用に比べて漏洩時の被害を抑えやすいとされています。仮にパスワードが第三者の手に渡っても、スマホや生体情報まで揃わない限り突破されにくくなるためです。

 

4. OAuth 2.0 と OpenID Connect の基本

4. OAuth 2.0 と OpenID Connect の基本

OAuth 2.0 とは、第三者アプリに「自分の代わりに API を呼ぶ権限」を委ねる仕組みです。重要なのは、パスワード自体を渡さずに権限だけを渡せる点です。

たとえば新しい家計簿アプリに銀行口座を連携するとき、銀行のパスワードを直接教えるのは不安ですよね。OAuth 2.0 を使うと、銀行側で発行されたアクセストークンという「権限の札」だけを家計簿アプリに渡せます。

 

OAuth 2.0 の要点
・パスワードではなく「アクセストークン」を渡す
・トークンには有効期限と権限範囲が設定される
・あくまで「認可」を委譲する仕組み(本人確認は別)

 

ここで注意したいのが、OAuth 2.0 はあくまで「認可」の仕組みであるという点です。「誰がログインしたか」という本人確認の役割は、OAuth 2.0 単体には含まれていません。

そこを補うのが OpenID Connect(OIDC)です。OAuth 2.0 の上に「本人確認」の層を追加で載せた拡張仕様で、ID トークンという形で「誰がログインしたか」を伝えられます。

 

「SNS アカウントでログイン」型のサービスでは、この OAuth 2.0 + OIDC の仕組みが裏側で動いていることが一般的です。

 

業務システムで OAuth 2.0 や OIDC を使う場面では、生成AIなど外部サービス連携時にも「どの権限まで委ねるか」が論点になります。たとえばプロンプトインジェクションのような攻撃では、AIに与えた認可の範囲がそのまま被害範囲になる場合もあります。

あなたが業務で外部連携を検討するときは、「渡している権限は本当に必要な範囲か」を立ち止まって確認すると安心です。判断に迷うときは、社内ガイドラインを確認の上で情シス・セキュリティ部門に相談するのがおすすめです。

 

まとめ: 今日からできる、最初の一歩

まとめ: 今日からできる、最初の一歩

ここまで、認証と認可の違い、多要素認証、OAuth 2.0 と OpenID Connect の基本を整理してきました。

4つの要点を振り返ります。

1. 認証=あなたが誰かを確かめる
2. 認可=何をしてよいかを決める
3. MFA=知識・所持・生体のうち2つ以上を組み合わせる
4. OAuth / OIDC=パスワードを渡さずに権限と本人確認を委ねる

これらは、基本情報技術者 領域5 情報セキュリティの中核テーマとして問われます。

 

今日からできる、最初の一歩
1. 自分のメインアカウントで MFA が有効か確認する(5分)
2. 認証 / 認可 / MFA / OAuth の4語をノートに書き出す(10分)
3. 基本情報技術者 領域5 情報セキュリティの問題集を1問解いてみる(15分)

 

たった30分で、あなたのセキュリティ知識は確実に前に進みます。最初の一歩を踏み出した自分を、ぜひ褒めてあげてください。

 

次のステップ