「Googleでログイン」「Facebookでログイン」というボタン、見たことありませんか？

新しいWebサービスに登録するとき、わざわざメールアドレスやパスワードを入力しなくても、既存のアカウントでサクッとログインできる便利な機能です。実はこの裏側で動いているのが、今回解説する「OAuth 2.0（オーオース・ツー・ポイント・ゼロ）」という仕組みなんです。

「なんだか難しそう…」と思った方、安心してください。この記事では、OAuth 2.0の仕組みを身近な例えを使いながら、できるだけわかりやすく解説していきます。エンジニアの方はもちろん、「技術のことはよくわからないけど概念だけ知りたい」という方にも理解していただける内容を目指しました。

それでは、OAuth 2.0の世界を一緒に覗いてみましょう。

OAuth 2.0とは？パスワードを渡さずに許可を与える仕組み

OAuth 2.0を一言で説明すると、「あなたのパスワードを教えずに、他のアプリにデータへのアクセス許可を与える仕組み」です。

想像してみてください。あなたは一人暮らしをしていて、旅行中に友人に植物の水やりを頼みたいとします。このとき、どうしますか？

一番シンプルなのは、家の鍵を丸ごと渡すことです。でも、ちょっと不安ですよね。鍵があれば家中どこでも入れてしまいますし、もし鍵をなくされたら大変です。

もっと良い方法があります。「植物のある部屋だけ入れる合鍵」を作って渡すのです。これなら友人は水やりという目的だけを達成でき、あなたの寝室や貴重品には触れられません。しかも、旅行が終わったら合鍵を無効にすればいい。

OAuth 2.0は、まさにこの「目的限定の合鍵」を発行する仕組みなんです。

従来のやり方では、あるアプリがあなたのGoogleカレンダーにアクセスしたい場合、あなたのGoogleのパスワードをそのアプリに教える必要がありました。でもこれは危険です。パスワードを知られたら、メールも写真もドライブも、すべてにアクセスされてしまう可能性があります。

OAuth 2.0を使えば、「カレンダーの予定を読み取る権限だけ」をアプリに与えることができます。パスワードを教える必要はありません。これが、OAuth 2.0が現代のWebサービスで広く採用されている理由です。

認証と認可の違いを「ホテル」で理解しよう

OAuth 2.0を正しく理解するために、避けて通れない概念があります。それが「認証」と「認可」の違いです。この2つは似ているようで、実はまったく別のものなんです。

ホテルのチェックインを想像してみてください。

まず、フロントで身分証明書を見せますよね。スタッフはあなたの顔と身分証を照らし合わせて、「この人は確かに予約した山田太郎さんだ」と確認します。これが「認証（Authentication）」です。つまり、「あなたが誰であるか」を確認するプロセスです。

次に、スタッフはあなたに部屋の鍵を渡します。この鍵があれば、あなたは302号室に入ることができます。でも、他の部屋には入れません。これが「認可（Authorization）」です。つまり、「あなたが何をできるか」を決めるプロセスです。

ここで重要なポイントがあります。OAuth 2.0は「認可」の仕組みであり、「認証」の仕組みではありません。

OAuth 2.0は「このアプリに、あなたのカレンダーを読み取る権限を与えていいですか？」という許可を管理するものです。「あなたが本当に山田太郎さんかどうか」を確認するのは、OAuth 2.0の役割ではないのです。

では、「Googleでログイン」機能は認証じゃないの？と思った方、鋭いです。実は「Googleでログイン」のような機能は、OAuth 2.0を拡張した「OpenID Connect」という別の仕組みを使っています。これについては後ほど詳しく解説しますね。

OAuth 2.0の4人の登場人物を覚えよう

OAuth 2.0の世界には、4人の重要な登場人物がいます。この4人の役割を理解すれば、OAuth 2.0の仕組みがグッとわかりやすくなります。

リソースオーナー（あなた自身）

リソースオーナーは、データの持ち主です。ほとんどの場合、これは「あなた自身」を指します。

Googleカレンダーに保存されているあなたの予定、Dropboxに保存されているあなたのファイル、Twitterに投稿したあなたのツイート。これらのデータの所有者は、すべてあなたです。そして、このデータを他のアプリに使わせるかどうかを決める権利も、あなたにあります。

クライアント（あなたの代わりに動くアプリ）

クライアントは、あなたのデータにアクセスしたいアプリケーションのことです。

たとえば、「Googleカレンダーと連携できるタスク管理アプリ」を使いたいとします。このタスク管理アプリが「クライアント」です。クライアントは、あなたの許可を得て、あなたの代わりにGoogleカレンダーのデータを取得します。

認可サーバー（許可証を発行する窓口）

認可サーバーは、アクセス許可を管理し、「許可証（トークン）」を発行するサーバーです。

先ほどの例でいえば、Googleの認可サーバーがこれにあたります。「このタスク管理アプリに、山田さんのカレンダーを読み取る権限を与えていいですか？」とあなたに確認し、OKが出たら許可証を発行します。

リソースサーバー（データの金庫）

リソースサーバーは、実際にあなたのデータを保管しているサーバーです。

Googleカレンダーの予定データが保存されているサーバー、これがリソースサーバーです。クライアントが許可証（トークン）を持ってきたら、その許可証が有効かどうかを確認し、許可された範囲内でデータを渡します。

この4人の関係を整理すると、こうなります。リソースオーナー（あなた）が、クライアント（アプリ）に対して、認可サーバー（窓口）を通じて許可を与え、クライアントはその許可証を使ってリソースサーバー（金庫）からデータを取得する。これがOAuth 2.0の基本的な構造です。

OAuth 2.0の認可フローを図解で追ってみよう

さて、ここからはOAuth 2.0の実際の流れを見ていきましょう。最もよく使われる「認可コードフロー」を、映画のチケット予約に例えて説明します。

あなたは、映画チケット予約アプリを使いたいとします。このアプリは、あなたのGoogleカレンダーに予約した映画の予定を自動で追加してくれる便利な機能があります。

ステップ1：アプリが許可を求める

映画アプリを開くと、「Googleカレンダーと連携する」ボタンがあります。あなたがこれをクリックすると、アプリはGoogleの認可サーバーに「この人のカレンダーにアクセスしたいんです」とリクエストを送ります。

ステップ2：あなたがGoogleにログインする

画面がGoogleのログインページに切り替わります。ここであなたは、自分のGoogleアカウントでログインします。このとき、パスワードを入力する相手はGoogleだけです。映画アプリにはパスワードは渡りません。

ステップ3：アクセス許可を確認する

ログインすると、「映画アプリがあなたのGoogleカレンダーにアクセスすることを許可しますか？」という確認画面が表示されます。ここで「許可する」を選ぶと、次のステップに進みます。

ステップ4：認可コードが発行される

あなたが許可すると、Googleの認可サーバーは「認可コード」という一時的なコードを映画アプリに渡します。これは、まだ「許可証」そのものではありません。「許可証を受け取る権利があることの証明」のようなものです。

ステップ5：認可コードをアクセストークンに交換する

映画アプリは、受け取った認可コードを認可サーバーに提示して、「アクセストークン」という本物の許可証と交換します。このアクセストークンがあれば、カレンダーにアクセスできるようになります。

ステップ6：データにアクセスする

映画アプリは、アクセストークンを使ってGoogleカレンダー（リソースサーバー）にアクセスし、映画の予定を追加します。

なぜこんな複雑な手順を踏むのでしょうか？実は、認可コードを挟むことでセキュリティが高まるんです。アクセストークンが直接URLに表示されることを防ぎ、悪意のある第三者に盗まれるリスクを減らしています。

ちなみに、アクセストークンには有効期限があります。期限が切れたら、「リフレッシュトークン」という別のトークンを使って、新しいアクセストークンを取得できます。これにより、毎回ログインし直す手間が省けるわけです。

OAuth 2.0の4つの認可方式（グラントタイプ）

OAuth 2.0には、状況に応じて使い分ける4つの認可方式（グラントタイプ）があります。先ほど説明した「認可コードフロー」は、その中の1つです。

認可コードグラントは、最も安全で推奨される方式です。Webアプリケーションで広く使われています。先ほど説明したように、認可コードを経由してアクセストークンを取得するため、トークンが外部に漏れにくい構造になっています。

インプリシットグラントは、かつてシングルページアプリ（SPA）で使われていた方式です。認可コードを挟まず、直接アクセストークンを受け取ります。シンプルですが、トークンがURLに露出するリスクがあるため、現在は非推奨とされています。代わりに、PKCEという拡張機能を使った認可コードグラントが推奨されています。

クライアントクレデンシャルズグラントは、ユーザーが介在しないサーバー間通信で使われます。たとえば、バックエンドサーバー同士がデータをやり取りする場合に使います。ユーザーの許可は必要なく、アプリ自身の認証情報だけでトークンを取得します。

リソースオーナーパスワードグラントは、ユーザーのIDとパスワードを直接アプリに渡す方式です。これは、アプリが完全に信頼できる場合（自社の公式アプリなど）にのみ使うべきです。外部のアプリにパスワードを渡すのはリスクが高いため、一般的には推奨されません。

多くの場合、認可コードグラントを選んでおけば間違いありません。

OAuth 2.0とOpenID Connectの違い

最後に、よく混同される「OpenID Connect」との違いを整理しておきましょう。

OAuth 2.0は「認可」の仕組みだと説明しました。「このアプリに、あなたのカレンダーを読み取る権限を与えていいですか？」という許可を管理するものです。

一方、OpenID Connectは「認証」の仕組みです。「この人は確かに山田太郎さんです」という本人確認を行います。

実は、OpenID ConnectはOAuth 2.0の上に構築された拡張仕様です。OAuth 2.0の仕組みをベースに、「この人が誰なのか」という情報も一緒に取得できるようにしたものがOpenID Connectなんです。

「Googleでログイン」「Facebookでログイン」といったソーシャルログイン機能は、多くの場合OpenID Connectを使っています。ログインすると、アプリはあなたが誰なのか（メールアドレスや名前など）を知ることができ、同時にカレンダーやプロフィールへのアクセス許可も得られます。

整理すると、こうなります。OAuth 2.0は「何ができるか（権限）」を扱い、OpenID Connectは「誰なのか（身元）」を扱います。そして、OpenID ConnectはOAuth 2.0を土台として使っています。この関係を覚えておくと、技術記事を読むときにも混乱しにくくなりますよ。

まとめ

この記事では、OAuth 2.0の仕組みについて解説してきました。最後に、重要なポイントを3つにまとめます。

1つ目は、OAuth 2.0は「パスワードを渡さずに、アプリにデータへのアクセス許可を与える仕組み」だということ。合鍵のように、必要な権限だけを必要な期間だけ与えることができます。

2つ目は、「認証」と「認可」は別物だということ。OAuth 2.0は認可の仕組みであり、本人確認（認証）には別途OpenID Connectなどが必要です。

3つ目は、OAuth 2.0には4人の登場人物（リソースオーナー、クライアント、認可サーバー、リソースサーバー）がいて、それぞれが役割を分担しているということ。この構造を理解しておくと、実装時にも迷いにくくなります。

OAuth 2.0は現代のWebサービスに欠かせない技術です。今回学んだ基礎知識をもとに、ぜひ実際の実装にもチャレンジしてみてください。公式のRFC 6749や、各プラットフォーム（Google、GitHub、Twitterなど）のドキュメントを読むと、さらに理解が深まりますよ。