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

OAuthって話す人によって言うことが違って矛盾に感じたことはないでしょうか？

この矛盾、実はどれも嘘ではなかったりします。が、OAuthの歴史的な背景や、複雑化した仕様を理解しておかないと混乱の渦に巻き込まれます。エンジニアでさえうまく説明できる人はどれくらいいるか。

今回は、OAuthについて、非エンジニアの方にも分かりやすく、極力専門用語は使わないように楽しんで読めるようにまとめてみましたので、ぜひ、お茶を片手に気楽に読んでいただければと思います。

それでは、早速いきましょう！

まず、OAuth2.0の矛盾に感じる部分についてひとつずつ分解して、明らかにしていきたいと思います。

OAuth2.0の矛盾の正体

そもそも、認証と認可というものが存在します。これについておさらいしておきましょう。

これだけ聞くと脳がクローズしちゃいそうですが、実は認可は誰でも見たことがあるはずです。

それが↓こちら。

そう、この画面こそが「認可の画面」。なんか、見たことありますよね？

「システムやアプリに、あなたの情報にアクセスする権限を与えてもいいですか？って聞かれる画面」

つまり、これを表示する仕組みに「OAuth2.0」の仕様が使われていると思っておいていただければと思います。

これだけでも、ちょっとだけOAuth2.0が身近に感じられたのではないでしょうか？

ただ、ややこしいことに、権限の仕様って認証といっしょに話さないといけないことが多く、なんなら認証の中に含まれることもよくあります。

まぁ、そこが話をややこしくする原因であり、完全に分離して話すのが難しかったりするポイントだったりもします。ただ、今回はそこをあえてきっちり分離して話していくのでご安心を！

さて、これを頭の片すみにおいて次に進みましょう。

今回の本題「OAuth」はその「認可」つまり権限の話になります。

そして、ずばり、先にOAuth2.0の矛盾の正体について話しちゃいます。それが↓こちらの３つです。

ひとつずつ見ていきたいと思います。

原因１．OAuth2.0は本当に矛盾していた

「OAuthは、頭のイかれた超天才が考えたものだから、自分には一生理解できない──」
かつての私は、本気でそう思っていました。

しかし、調べていくうちに、OAuthがシンプルに矛盾している事実も見つけてしまったのです。

それは、OAuthの誕生から今までに繰り広げられた、さまざまな登場人物や、政治や利権（言い過ぎ？）がからんでいました。

以下の年表をみてください。

OAuthは2007年、Twitterに在籍していたBlaine Cook（ブレイン・クック）氏らが中心となって策定、公開されました。

当時は、FacebookやTwitterが誕生したSNS黎明期。世の中を見渡してみると、まだ認証や認可の標準仕様が整っておらず、各社が自由に実装していました。かろうじてOpenIDがありましたが、仕様が複雑すぎて広まりきれずにいました。

そんな中、Twitter社が動きます。安全にユーザーにTwitterのAPIを公開する方法を模索がOAuthの誕生へとつながっていきます。

ある日、創始者のクック氏はこんなことを考えていました。

「IDとパスワードのやりとりは危険で古臭い。もっと良い方法はないか？」（想像）

そこでひらめきます。
「そうだ！許可だけ渡せばいいんだ！この仕組みを世界標準にして、TwitterのAPIをみんなに使ってもらおう！」（想像）

こうして、OAuthに準拠したAPIが誕生しました。

ところが、このOAuthも仕様が複雑だったため、なかなか正しく理解できるエンジニアがいませんでした。

そんなある日、あるエンジニアがOAuthに準拠したAPIを使って認証にも使える仕組みを作ってしまいます。これが大ヒットし、またたく間に世の中に広がっていきました。

ここからOAuthの長い暗黒時代となります。

魔改造のOAuthとは？

「魔改造のOAuth」とは何か？気になりますよね。まずは、本当のOAuthの画面の流れを見てみましょう。

本当のOAuthのイメージ

ここでは、あるアプリが自分のTwitter（X）の最新投稿を取得しアプリに表示する例で説明します。

まずは正しいOAuthの流れから。

前提として、CさんはすでにTwitterにログイン済みです。

Cさんがアプリの取り込み画面を開き、「あなたのツイートを取り込もう！」をクリック。
すると、OAuthの認可画面が表示され、「はい」をクリックすると、アプリはTwitterの自分の情報にアクセスする許可を得ます。

その結果、アプリはCさんのTwitter最新投稿を取得し、アプリ内に埋め込むことに成功しました。

つまり、ログインIDやパスワードを使わずに認可だけを得ることに成功し、まさにBlaine Cook氏の狙い通りの仕組みなのです。

魔改造のOAuthのイメージ

それでは、次に「魔改造OAuth」の流れを一緒に見ていきましょう。今回は、ある通販サイトにCさんのTwitterアカウントでログインするケースです。

前提として、今回もCさんはすでにTwitterにログイン済みです。

その状態で通販サイトのログイン画面にある「Twitterのアカウントでログイン」をクリック。
するとTwitterからアクセス権限の許可を求められ、Cさんは「許可」をクリックします。

すると通販サイトはCさんのTwitterの個人情報をさまざま取得でき、これを使って通販サイト側でログイン状態を作ります。

つまり、OAuth2.0（認可）を使ってログイン（認証）できるように魔改造しちゃったんですね。

これにより、「OAuth認証」という本当に矛盾した状況ができてしまいました。そして、この方法を採用しているシステムが今でもまだ多く存在すると言われています。

原因２．OAuth2.0には２つの顔があった！

そして２つ目。それは、OAuth 2.0の持つ２つの顔についてです。
これを知らないと、まったく違う話になり話がかみ合わないこともよくあります。

まずは、こちらを御覧ください。

１つ目の顔：ユーザーの認可

１つ目の顔は、OAuthの王道ともいえる「ユーザーの認可」。
ユーザーが画面で『はい』か『いいえ』を選ぶあのイメージですね。

２つ目の顔：ユーザーが関与しない認可

２つ目の顔は、「APIの認可」です。
たとえば、「TwitterのAPIで人気の投稿を取得する」みたいなときの話。この場合、自分の情報を渡すわけじゃないので、人に対する認可（認証も）いりません。

必要なのは、TwitterからAPIを呼ぶ許可だけです。そう、OAuth2.0には、このユーザーが関与しない権限の仕様も含まれているんですね。

この２つの違いは、OAuth 2.0の仕様にも明確に記載されていますので、すこしくわしく見ていきたいと思います。

Auth2.0のコアの仕様を見ても一目瞭然！

ここでは、OAuth 2.0のコアの仕様をサラッと確認しておきたいと思います。

まずは以下の図を御覧ください。

OAuth2.0には、4つの種類があると書かれています。フローというのはプログラムの流れだと思ってサラッと流していただいて構いません。

ここで、先程の話を思い出してください。

1つ目の顔が「ユーザーの認可」、２つ目が「ユーザーが関与しない認可」でしたね。

これは、↑の図でいくと「ユーザーの認可」が１段目の「Authorization Code Flow（認可コードフロー）」、「ユーザーが関与しない認可」が４段目の「Client Credentials Flow（クライアントクレデンシャルフロー）」に該当します。

真ん中の2つは非推奨となっているので、実質、この２つのフローだけ頭にいれておけばOKです。

つまり、この２つの存在を頭に入れておくことが非常に、非常に、非常ーーーに重要ということです。（後でまた出てくるのちょっと強めに主張してみました笑）

APIの認可がOAuthにあるって違和感、ありませんか？

ここでなにか腑に落ちないあなた・・・その感覚、めちゃくちゃ正しいです！

OAuthはもともとユーザーに権限を付与するために生まれました。でもOAuth 2.0では、ユーザーが関わらないAPI同士の通信（API認可）の仕組みが追加されてしまったんです。つまり、OAuthの範囲が広がっちゃったんですね。

なんで、こうなってしまったのか？ChatGPTさんにインタビューしてみました（ゆるく茶番にお付き合いください）

Q. なんで、APIの認可の仕様がOAuth2.0に追加されちゃったの？

✅ 実務上、必要だったから。

• バックエンド同士（API to API、マイクロサービス間）でセキュアに通信する仕組みが必要だった。
• ベーシック認証やAPIキーより、トークンベースの認証の方が安全でモダン。
• OAuthの仕組みを流用すれば、既存の認可サーバーを再利用できて便利。

なんだか、大人の事情みたいなのもあったんでしょうね。

さらに、こんなことも聞いてみました。

| 設計者たちも「OAuth2.0は矛盾している」と感じていた？

はい、実際そうです。
OAuthの初期設計者である Eran Hammer 氏はこう語ってます：
"Client Credentials Flow is just a secure way to authenticate a system to another system.
It's technically part of OAuth 2.0, but philosophically it's not OAuth."
（訳）クライアント・クレデンシャル・フローは技術的にはOAuth 2.0の一部だけど、思想的にはOAuthじゃない。

設計者たちも、抗えない力と戦った末の苦渋の決断だったのかもしれません…💧

原因３．OAuth2.0が矛盾を抱えたままOIDCが登場！

OAuth2.0の混乱と暗黒時代に光を差すべく登場したのがOIDC（OpenID Connect）でした。しかし、現場ではまだまだOAuth魔改造認証全盛期。
一度おかしくなった仕様を元に戻すのは簡単ではありませんでしたが、少しずつ真実に気づく人たちが増えていきます。

ここで、OIDCについて改めておさらいしましょう。

OIDC（OpenID Connect） とは

OIDCとは、OAuth2.0の認可の仕組みをベースに「認証」を追加した新しい仕様です。
言い換えれば、OAuth2.0の認可フローを利用しながら、ユーザーが「誰か」を確認できる仕組み。
そのため、OIDCはシングルサインオン（SSO）の標準仕様としても広く使われています。

OAuth1.0が誕生したのは2007年、OIDCの登場は2014年と、約7年の歳月を経てようやく認証の標準仕様が明文化されました。

ただし、OIDCが認証を担う一方で、ユーザーの認可は引き続きOAuth2.0の役割です。つまり、OIDCが登場してもOAuth2.0自体はなくなりません。OAuth認証がなくなっただけ。

大きく変わった！OIDCの環境とは？

OAuthとOIDCの違いのひとつに、必要なシステム構成の違いがあります。

OAuthでは、「認可サーバー」だけを用意すればユーザーに権限を与えることができました。しかしOIDCになると、権限に加え、ユーザーを管理・認証するための仕組みも必要になります。そこで登場するのがIDプロバイダ、通称IdP（アイ・ディー・ピー）です。

表にまとめるとこんな感じ。

	OAuth 2.0	OIDC
認可サーバー	◎必須	◎必須（IdPに含まれることが多い）
IDプロバイダ（IdP）	✕不要	◎必須

ただ、IdPは２つの機能を兼ねていることがほとんどです。そのため、OIDCではIdPを1つ用意すれば認可も認証もまかなえるのがいいところです。

ちなみに、IdPとして使える代表的なサービスには以下のようなものがあります：

• クラウド系：AWS Cognito、Azure AD、Google Identity、Auth0、Okta、OneLogin、Ping Identity
• OSS系：Keycloak、Gluu、Dex
• 日本のID連携系：LINE Login、Yahoo! JAPAN ID、楽天ID など

OIDCが登場して画面はどう変わった？

では、OIDCが登場すると、あの“魔改造OAuth”たちはどう変わったのでしょうか？比較してみましょう。

ご覧の通り、OIDC、魔改造OAuth、見た目はほとんど変わりません。そりゃそうですよね。魔改造を作った人はこれがしたかったんですから。

ただし、前述のとおり、IdPには権限を設定する機能があるので、やりかた次第で認可の画面をスキップすることが可能です。

そうなると、もはや魔改造の時代は終わり、OIDC時代になりそうですね！

OIDCにも認可フローが登場して混乱の渦に！

OIDCも登場してくれて、OAuth2.0の矛盾も解決してめでたしめでした。

なんですが、舞台に新たなプレイヤーが現れたことで、現場は混乱の渦に――

その中の一つに、「OIDCにも３種類の仕組みがあり、その１つがOAuth2.0と被っている」というのがあります。

先程のOAuth2.0と比べてみましょう。

下の図を御覧ください。左がOAuth2.0、右がOIDCです。

左のOAuth2.0には前述の「Authorization Code Flow」というフローがあります。

一方、OIDCにもまったく同じ名前の「Authorization Code Flow」が存在します。（本当はOAuth2.0はFlowでなくGrantだったりしますがどっちでもいいので割愛）

これは何を意味しているかと言うと、OIDCはOAuth2.0の認可フローのしくみを一部採用しているということを表しています。（本当にざっくり）

ただ、ここで混乱しやすいのが、「Authorization Code Flow」には、

という２つの意味が存在することになります。

この違いも理解していないと、どっちの話をしているのか話が噛み合わなくなるので、ぜひここも頭に入れておいてくださいね！

この図の違いを理解することで、それぞれの役割――OAuth2.0は何を担当し、OIDCは何を補完しているのか――が見えてきます。

まとめ：OIDCとOAuth2.0の今後の棲み分け

最後に、OIDCとOAuth2.0の今後の棲み分けについて整理して終わりにしたいと思います。

	OAuth 2.0	OIDC	備考
ログイン	✕	◯ Authorization Code Flow	OIDCはid_tokenで認証。OAuthは認証の仕様を定義していない
SSO	✕	◯ Authorization Code Flow	OIDCはIdPを通じてSSO実現可。OAuth単体ではできない
API通信 （マシン間）	◯ Client Credntial Flow	✕	OAuthのClient Credentials Flowはマシン間通信向き
従来の認可 （アクセスしていいですか？）	◯ Authorization Code Flow	✕	OAuth 2.0の主目的は認可。OIDCは認証寄りなので✕
新しい認可 （IdPで権限を管理）	✕	◯ Authorization Code Flow	OIDCはSCOPEなどにより権限情報を渡せるが、認可判断はアプリ側

OAuth2.0は、認証を伴わない従来の「認可」フローと、API間通信（システム対システムの認可）の２つの役割、OIDCの一部として、今後も使われ続けます。

一方で、OIDCはログインやシングルサインオン（SSO）などの認証基盤として、今後ますます普及していくでしょう。

OIDCの登場によって、OAuth2.0は本来の目的に専念できるようになり、それぞれ正しい用途で使っていくことができるようになりました。

---

さいごに

以上、**「OAuth 2.0は本当に矛盾していたのか？」「OAuth 2.0には別の顔があった？」「OIDCの登場でさらなる混乱？」**といった視点から、OAuth 2.0の本質やその限界、そしてOIDCとの関係について解説してきました。

少しでも、あなたの理解の手助けになっていれば嬉しいです！ここまでお読みいただき誠にありがとうございました。

※もし記載に誤りや不明点があれば、ぜひコメント欄からご指摘いただけると助かります。