OAuth登場前にあった複数サービス連携の課題🔑

本記事では、OAuth登場前に複数サービスを連携させようとしたときに直面した課題を整理し、それがOAuthによってどう解決されるのかを見ていきます。

対象外
実装のベストプラクティスやセキュリティ強化策を探している方

この記事の内容は、以下の書籍を主な参考にしています。

背景 🖼️

OAuthの仕組みについて以下の記事の執筆を通して概要をつかみました。

しかしOAuthはどんな課題を解決する仕組みなのかについては曖昧でした。
今回はそこに注目して整理します。

まず最初の二つの章でおさらいをします。

• OAuthとは
• 車のバレットキーで理解するOAuthの仕組み

その後、本題の「なぜ必要なのか」に入っていきます。

OAuthとは 💡

リソース所有者が、外部のアプリにリソース所有者の代わりになってリソースにアクセスする際に何ができるかを許可する仕組みのことです。
OAuthは認可の仕組みです。

認可とは
何ができるか（リソースを利用すること）を許可する仕組みのことです。
例えば「残高を参照できるが送金はできない」といったように、操作範囲を制御します。
※OAuthは認可の仕組みであり、ログイン（認証）そのものを扱うわけではありません。
認証についてはOIDCという仕組みがありますが、本記事では扱いません。

次に車のバレットキーを例に説明します。

車のバレットキーで理解するOAuthの仕組み 🗝️

バレットキーとは
ホテル等で車のバレットパーキング（駐車代行）サービスに使う、ドア解錠やエンジン始動など、駐車に必要な最小限の機能だけを持つ特別な車の鍵です。

日本ではあまり馴染みがないかもしれませんが、海外や高級ホテルではよく使われるそうです。
メルセデスベンツにはあるみたいです✨
https://www.mercedesbenz-net.com/entrance/basic_jituyou.html

バレットキーを渡すことで目的地まで運転することしかできないです。
これにより安全に車を貸すことができます。

OAuthのトークンもこの例と同様に外部アプリが行えることをリソース所有者が許可したことしかできないよう制限することが可能です。

次に本題であるOAuthがなぜ必要なのかについて説明します。

OAuth登場前の複数サービス連携の課題〜クレデンシャルの共有〜 🤝

クレデンシャル情報とは
ユーザーのIDとパスワード等の認証に用いられる情報のことです。

ここからはネット銀行と家計簿アプリを例に説明します。

以下の用語を使います

• リソース所有者：ユーザー本人
• クライアント：ユーザーのデータ（リソース）を使いたいアプリ
• 保護対象リソース：ユーザーのデータを持っているサービス

ネット銀行と家計簿アプリが同一ドメインである場合

これはリソース所有者がクライアントと保護対象リソースで同じクレデンシャルを使う必要があります。
まず保護対象リソースにログインし、発行されるcookieにセッションIDを渡します。
クライアントはcookieを取得して保護対象リソースにセッションIDを使用してユーザーになりすましてログインします。

保護対象リソースから見ると、ログインしてきたのがリソース所有者本人なのか、クライアント経由なのか区別できません。

ネット銀行と家計簿アプリが別ドメインの場合

cookieは同一ドメイン間でしか共有できないため、セッション状態を直接共有することはできません。

そのため「ユーザーへの問い合わせ」という手法を使います。

これはクライアントがリソース所有者に保護対象リソースへのクレデンシャルを要求します。
リソース所有者がそこでID、パスワードをそのままクライアントに提供することでクライアントは保護対象リソースにログインします。

しかし、このクレデンシャルが第三者に漏洩した場合、別の環境からもログイン可能になってしまうリスクがあります。

今回はリソース所有者のパスワードを再使用してユーザーの代わりに保護対象リソースへアクセスすることの問題を説明しました。

次に万能な開発者キーを使用した保護対象リソースへのアクセスについて説明します。

OAuth登場前の複数サービス連携の課題〜万能な開発者キー〜 💪

開発者キー＝すべての口座操作ができる1本の合鍵

クライアントにクレデンシャルが渡されていないので、クレデンシャルの漏洩のリスクはありません。
しかし、クライアントには強力な権限があります。
これは例えば他のユーザーの口座情報を参照できたり、送金したりできる可能性があります。
また、クライアント自身のクレデンシャルが盗まれると多くのリソース所有者に影響を与えるリスクがあります。

OAuth登場前の複数サービス連携の課題〜リソース所有者にクライアント用のクレデンシャルを提供する〜 🔑

この方法は以下のメリットがあります。

• リソース所有者が保護対象リソースにログインする際のクレデンシャルをクライアントと共有しない
• 強力な権限を持つ万能なキーをクライアントに渡さないで済む

しかし、この方法はリソース所有者に対して負担になります。
すでに「自分用のメインのキー」を管理しているのに加えて、クライアントが使うクレデンシャルも別途管理する必要があります。
また、不要になったクライアント用クレデンシャルを失効させずに放置すると、そのアプリから依然として保護対象リソースにアクセスできてしまいます。

権限（アクセス権）を制限したクレデンシャルをリソース所有者とクライアントの組み合わせごとに発行できてそれを保護対象リソースへのアクセスに使用できるような仕組みがあるでしょうか？

これを解決するのがOAuthです。

課題を解決するOAuthの仕組み ✨

OAuthではリソース所有者は保護対象リソースへのアクセス権を限定したものをクライアントに許可し、クライアントはリソース所有者の代わりに保護対象リソースへアクセスします。

ここで新たに認可サーバーという要素を仕組みを加えます。

認可サーバーとは

• 保護対象リソースに信頼されているサーバー
• 保護対象リソースへ制限したアクセスをする為のクレデンシャル（アクセストークン）をクライアントに発行する

まずクライアントは、認可サーバーを通してリソース所有者にクライアント自身の保護対象リソースへのアクセス権を要求します。
クライアントはアクセス権を要求する際にスコープというものを指定します。
これは権限を指定するもので、リソース所有者が不要な権限をクライアントに与えないことを可能にします。
次に認可サーバーがリソース所有者に要求されたアクセス権を付与するか決めさせます。
付与することを許可された場合は認可サーバーがアクセストークンを発行します。
そしてこのアクセストークンをクライアントに付与します。
クラインアントはこのトークンを使用して保護対象リソースにアクセスすることができます。

この仕組みだと前の章で述べたOAuth登場前の課題を解決できます。

• リソース所有者のクレデンシャルがクライアントに共有されない
• クライアントに与えられたトークンは権限が限られているのでリソース所有者が代理で依頼したい操作のみしかできない
• 一般的にリソース所有者はこのアクセストークンを管理する必要はない

まとめ 🌈

本記事ではOAuth登場前の複数サービス連携の課題を整理しました。

• OAuthが登場する前、複数サービスを連携させる方法には以下の課題がありました

  • クレデンシャルの共有：ユーザーのID/パスワードを直接渡すリスク
  • 万能な開発者キー：権限が強すぎて被害範囲が大きい
  • クライアント用クレデンシャルの発行：ユーザーに過剰な管理負担

• OAuthではこれらの課題を解決する仕組みを提供します

  • ユーザーのクレデンシャルを外部アプリに共有しない
  • アクセス権をスコープで限定できる
  • 認可サーバーがアクセストークンを発行するため、ユーザーの負担が軽い

つまり、OAuthは「必要な権限だけを安全に外部サービスに渡すための標準的な仕組み」です。

「追記」LTに登壇し、この記事の内容を話しました

LTで頂いた質問が以下です。まだ勉強不足なところもあるので引き続き精進します🙇‍♂️

OAuthを導入してもUXの観点で課題が残るケースはあるか？

質問で述べられた認可画面での同意疲れや複雑さなどは同意でその他はすぐに思い付かなかったです。勉強します。

OAuthの落とし穴をあえて上げるなら何ですか？

特定の保護対象リソースに依存しすぎると、そのサービスが利用できなくなった際にクライアントサービス自体も停止してしまうリスクがあります。
他についてはまた勉強します。

普段Googleでログインとか、GitHubでログインとか、他のサービスのアカウントでログインするときに使われている技術という理解であってますか？？

はい、ご認識の通りです。
ただ、まだ自分の言葉でわかりやすく説明できる段階ではないので、今後しっかり勉強していきたいと思います。

リソース所有者が外部アプリへの許可を取り消す仕組みはありますか?

多くのサービス（保護対象リソース）では、アカウント設定から接続済みアプリ一覧を確認でき、不要なアプリのアクセス権を取り消すことができます。

認可サーバは独立しており、外部アプリ(今回は家計簿アプリ)所有でもオンライン銀行のものでもないのでしょうか？

外部アプリ(今回は家計簿アプリ)所有ではないです。保護対象リソースであるオンライン銀行が認可サーバーを担っている場合と、認可サーバが独立しているケースがあります。この点はRFCでも厳密には定義されていなかったと思います。

The authorization server may be the same server as the resource server or a separate entity
認可サーバーはリソースサーバーと同じサーバー上にあってもよいし、別々のサーバーとして分離されていてもよい。

参考 📚

• https://www.shoeisha.co.jp/book/detail/9784798159294
• https://www.mercedesbenz-net.com/entrance/basic_jituyou.html
• https://tech.iimon.co.jp/entry/2025/05/13/180000

今後勉強したいこと 🏃‍♀️

• OIDC（OpenID Connect）による「認証」の仕組み
• OAuthのセキュリティに関する実践的な手法
• OAuth徹底入門を読み込む

最後までご覧いただきありがとうございました🙏