はじめに
Webサービスを使っていると、「Googleでログイン」 や 「Twitter(X)と連携」 といったボタンをよく見かけませんか？
ボタン一つで連携できて便利ですが、裏側で一体何が起きているのか、不安に思ったことはないでしょうか。
「勝手にパスワードが見られたりしないの？」
「全部の情報が抜き取られたりしない？」
この連携の裏側で動いている仕組みが、OAuth 2.0（オーオース 2.0） です。
この記事では、エンジニアではない方や初学者の方に向けて、OAuth 2.0の仕組みを「ホテルのカードキー」に例えて解説します。
1. なぜOAuthが必要なの？（合鍵問題）
OAuthが登場する前、アプリAがアプリBのデータを使いたい場合、一番手っ取り早い方法は**「IDとパスワードを教えること」**でした。
しかし、これは現実世界で言うと、**「家の掃除を代行業者にお願いするために、家の合鍵（マスターキー）を渡す」**ようなものです。
合鍵（ID/PASS）を渡すリスク
- 業者が、掃除以外の部屋（見られたくないデータ）に勝手に入るかもしれない。
- 業者が合鍵をなくしたら、家中のセキュリティが崩壊する。
- 契約終了後に鍵を返してもらったか確認できない（パスワードを変えるしかない）。
「掃除だけしてほしいのに、家全体の権利を渡すのは怖すぎる」。
そこで必要になったのが、「掃除する部屋だけに入れる、期間限定のカードキー」を渡す仕組みです。これがOAuthの考え方です。
2. 登場人物を「ホテル」で整理する
OAuthの仕組みは少し複雑なので、**「ホテルの宿泊客とルームサービス」**に置き換えるとスッキリ理解できます。
| 専門用語 | この記事での呼び名 | ホテルの例え | 役割 |
|---|---|---|---|
| Resource Owner | ユーザー | 宿泊客（あなた） | データの持ち主。 |
| Client | Webアプリ | デリバリー業者 | あなたの部屋に荷物を届けたい人。 |
| Authorization Server | 認可サーバー | ホテルのフロント | 鍵（権限）を発行する係。 |
| Access Token | アクセストークン | カードキー | 指定された部屋に入れる鍵。 |
Webアプリ（デリバリー業者）は、あなたのID・パスワードを知りません。持っているのは、フロントから発行された**カードキー（トークン）**だけです。
3. 全体の流れ（図解）
では、実際に「Webアプリ」が「Googleフォトの写真」にアクセスする場面を想像してみましょう。
（「デリバリー業者」が「あなたの部屋」に入室する流れと同じです）
ポイント解説
-
パスワードはGoogle（フロント）にしか渡さない
Webアプリ（業者）には、あなたのパスワードは一切知らされません。ここが最も重要です。 -
認可コード（引換券）の存在
いきなり鍵を渡さず、一度「引換券」を挟むことで、セキュリティを高めています（これを認可コードグラントといいます）。 -
トークン（カードキー）は限定的
このカードキーは「写真を見るだけ」の権限しかありません。「メールを見る」や「パスワードを変える」ことはできません。
4. よくある間違い：「認証」と「認可」
最後に、よく混同される言葉の違いを整理しておきましょう。
-
認証 (Authentication): あなたが「誰か」を確認すること。
- 例：ホテルのチェックイン時に身分証を出すこと。
-
認可 (Authorization): あなたに「何をする権限を与えるか」を決めること。
- 例：特定の部屋に入れるカードキーを渡すこと。
OAuth 2.0は、名前の通り**Auhtorization（認可）**の仕組みです。「誰か」を特定するためにも使われますが、本質は「鍵（権限）の貸し借り」にあると覚えておきましょう。
OpenID Connect (OIDC) とは？
OAuth 2.0（鍵の受け渡し）の仕組みを使って、ついでに「この人は誰？」という身分証明（認証）もしちゃおう！という拡張規格です。
「Googleでログイン」の多くは、実際にはこれを使っています。
まとめ
この記事のポイントを振り返ります。
-
OAuth 2.0の本質
- ID/パスワードを教えずに、アプリに権限だけを貸す仕組み。
-
イメージは「カードキー」
- 「合鍵（全権限）」ではなく、用途が限定された「ホテルのカードキー（限定権限）」のようなもの。
-
Webアプリの動き
- Webアプリは、アクセストークンを使ってデータのやり取りを行う。
この仕組みのおかげで、私たちは安全にいろいろなサービスを連携させて使うことができているのです。