【図でやさしく解説】非エンジニアでもわかるOAuth 2.0｜ややこしさの正体は“歴史”にアリ！

2025/06/02 2025/06/06

ナナスタ

認可とは「権限」のこと。認証は「本人確認」。そして、今回の主役OAuthはずばり「認可」の担当です。

ところが、OAuthについて勉強していると「OAuth認証」「OAuthログイン」みたいな使われ方を目にしたことはないでしょうか？

そうなんです。OAuthって認可だけのはずなのに認証にも使われているんです。

この記事では、図をつかって、非エンジニアの方向けに、できるかぎり分かりやすく、“歴史”からたどってスッキリ解決していきます。

まずは、OAuthの矛盾の原因が何なのか？そこから見ていきましょう。

OAuthの誕生秘話

OAuthは2006年、Twitterに在籍していたBlaine Cook（ブレイン・クック）氏らによって発案されました。当時、Twitte社はAPIの公開に力を入れていました。そこで、新たな安全な通信方法をを模索していたのです。それがOAuthのきっかけでした。

APIってのは、他者に自社の機能を提供するときの接続口みたいなものです。

ここでクック氏はOAuthは「認可だけに特化させよう」と割り切っていました。理由はシンプル。「認証」はサービスごとに事情がバラバラで、共通の仕組みをつくるのが難しかったから。

でも「この人がこのアプリにアクセスを許可したか？」だけなら、共通ルールで十分いける。だからOAuthはそこだけを担当することにしたわけです。

つまり、「OAuthは許可しかやらん！」「認証のことは他でよろしく！」という潔い設計なんですね。

2009年頃になると、OAuth2が生まれてより簡単に安全な認可ができる仕組みになっりました。OAuth1と2で互換性はありません。

ところが現実は少し違っていました。フタを開けてみると、APIを使ってユーザーの名前やメールアドレスなどが手に入ってしまったんですね。これって、本人確認に使えてしまう。

「だったら、OAuthでログインしたら早いじゃん！」と、各社が認証用途に使い始めたんです。これが俗に言う「OAuthログイン」の始まりです。

でもこれは、OAuthはあくまで「アプリにアクセスを許可するための仕組み」。本来の使い方ではありません。これはOpenID Connect（OIDC）のことですが、OIDCが普及するのはまだずっと先のことです。

皮肉なことに、この「誤用」の中心にいたのもTwitter社。そしてOAuthの発案者、ブレイン・クック氏は一貫して「OAuthは認可のみ」と主張していたので、もしかすると、彼自身はこの流れを良しとは思っていなかったのかもしれません。その後彼はOAuthから離れていくことになります。

このように、OAuth2.0が「ログイン」に使われている背景には、利便性にひっぱられた“魔改造”の歴史があったというわけです。

OAuth2.0には、実は２つの認可の使い方があります。ひとつは「ユーザーが画面で『はい』『いいえ』を選ぶ認可」。たとえば、スマホアプリがあなたの写真にアクセスするとき、許可を求めるポップアップが出るあれです。

もうひとつは「システム同士が直接やりとりする認可」。こちらは、人の操作なしにサーバー同士がスムーズに情報をやりとりするための仕組みで、画面は一切出ません。いわゆるAPIと呼ばれているやつです。

この２つは同じOAuth2.0でも、まったく別のルールで動いているので、話をするときは「どっちの話？」と意識するとわかりやすいんです。

実は、昔のOAuth1.0には、このシステム間認可のルールがなくて、かなり混沌としていました。これがOAuth2.0で「Client Credentials Flow」という新しいフローが生まれ、システム間の認可がやっと明文化されました。

OIDC（OpenID Connect）はOAuthの拡張です。パワーアップ版といっても間違いではないです。

OAuth（オーオース）は、「認可」の仕組みを提供するのが担当でしたね。

なので、OAuthには「このユーザーが本当に本人かどうかを確認する」ための仕組みは元々備わっていません。つまり、“本人確認”はOAuthの役割ではないのです。

そこで登場するのが OIDCです。OIDCはOAuthの「認証機能を加えた拡張」になります。簡単に言うと、

OIDCはOAuthに“本人確認”の仕組みをプラスしたもの

です。

OIDCを使うと、サービスはユーザーが本当に本人であることを確認できるようになります。たとえば、ログイン画面で「あなたは誰ですか？」と本人確認をする部分がOIDCの役割です。その後、OAuthの仕組みで「何をしていいか（認可）」を決める流れになります。

このように、OIDCはOAuthの上に成り立つ「拡張機能」であり、認証（本人確認）と認可（権限付与）をセットで実現できるようにした最新の仕組みと理解するとわかりやすいでしょう。