OAuth とは
OAuth(オーオース)は、パスワードを渡さずに、別のサービスにあるデータを使う許可を、範囲と期限を決めてアプリに渡す仕組みです。「Google でログイン」の土台にもなっています。
この記事でわかること
- OAuth がどんな困りごとを解決する仕組みかを説明できる
- 認可コードの流れと、スコープ・アクセストークン・リフレッシュトークンの役割がわかる
- OpenID Connect との違いと、許可を出す前と取り消すときに確かめることを知る
目次
OAuth(オーオース)は、あるアプリに、別のサービスにあるあなたのデータを使う許可を渡すための決まりです。パスワードを教える代わりに、使える範囲と期限が決まった「トークン」という合鍵をアプリに持たせます。いま広く使われているのは OAuth 2.0 で、インターネットの技術の標準を決める IETF が、RFC 6749 という文書で定めています。
予約のツールと Google カレンダーを連携するときの許可の画面や、「Google でログイン」のボタンの裏で動いているのが OAuth です。しくみを知っておくと、許可の画面で何を確かめればよいか、いらなくなった許可をどこで取り消せばよいかがわかります。
- アプリが頼むカレンダーを見せてください
- 本人が許可するサービスの画面で範囲を確認
- コードが届く使い捨てで、すぐ切れる
- トークンに換える範囲と期限の決まった合鍵
- API を使う許された範囲のデータだけ
OAuth はどんな困りごとを解決するのか
たとえば、オンライン講座を開いている人が、予約のツールに自分の Google カレンダーを読ませて、空いている時間だけを受講生に見せたいとします。仮に、予約のツールに Google のパスワードを預けるとしたら、次のような問題が起きます。RFC 6749 の冒頭でも、同じ問題が挙げられています。
- ツールがパスワードを保存し続けるので、ツールから漏れると、アカウントのすべてが危うくなる
- カレンダーだけでよいのに、メールや写真まで、何でもできてしまう
- 1 つのツールだけ止めたくても、パスワードを変えるしかなく、ほかのツールも全部止まる
OAuth では、パスワードはサービス自身のログインの画面にだけ入れます。アプリには、パスワードとは別の、範囲と期限が決まった合鍵(アクセストークン)が渡されます。ホテルのカードキーに似ています。カードキーは自分の部屋しか開けられず、泊まる期間が終われば使えなくなり、フロントで止めることもできます。建物全体の鍵を渡すのとは違います。
OAuth に出てくる 4 つの役割
OAuth の決まりは、登場するものを 4 つの役割に分けています。上の例に当てはめると、次のとおりです。
| 役割 | 何をするか | 例 |
|---|---|---|
| リソースオーナー | データの持ち主で、許可を出す | 講座を開いている本人 |
| クライアント | 許可を受けて、データを使う | 予約のツール |
| 認可サーバー | 本人を確かめ、許可を受けてトークンを発行する | Google のアカウントの仕組み |
| リソースサーバー | データを預かり、トークンを確かめて応じる | Google カレンダーの API |
認可サーバーとリソースサーバーは、同じ会社が動かしていることがよくあります。API そのものについては「API とは」で説明しています。
許可はどんな流れで渡されるのか
Web のアプリでいま基本になっているのは、「認可コード」を使う流れです。
- 予約のツールで「Google カレンダーと連携」を押すと、ブラウザーが Google のページに移る。このとき、ツールの名前と、求める許可の範囲(スコープ)が一緒に伝わる
- 本人が Google のページでログインし、同意の画面で内容を確かめて許可する
- Google が、使い捨ての「認可コード」を付けて、ブラウザーをツールへ戻す
- ツールが、そのコードを裏側(ツールのサーバーと Google のあいだ)で送り、アクセストークンに換えてもらう
- ツールは、アクセストークンを付けてカレンダーの API を呼び、許された範囲のデータだけを読む
本人がパスワードを入れるのは、手順 2 の Google のページだけです。ツールはパスワードを一度も見ません。
なぜコードを一度はさむのか
手順 3 でブラウザーのアドレスに載るのは、認可コードだけです。RFC 6749 は、認可コードを一度しか使えないものにし、発行してから短い時間で切れるようにすることを求めています。合鍵そのものは手順 4 の裏側のやりとりで渡るので、ブラウザーの履歴などから漏れにくくなります。
さらに、OAuth を安全に使うための勧めをまとめた RFC 9700(2025 年 1 月)は、PKCE(ピクシー)という仕組みを、スマートフォンのアプリやブラウザーの中だけで動くアプリには必須とし、サーバーを持つ Web のアプリにも勧めています。PKCE では、アプリが最初に秘密の値を作り、そのハッシュ(元の値に戻せない要約)だけを送っておきます。コードを換えるときに元の値を見せ、計算が合わなければ断られます。途中でコードを盗んだ人がいても、元の値を知らないので使えません。
RFC 9700 は、アプリが自分の画面で本人のパスワードを受け取るやり方を、使ってはならないとしています。
スコープとトークンとは何か
スコープと同意の画面
スコープは、アプリが求める許可の範囲です。「予定を見る」「予定を変える」「メールを読む」のように分かれていて、どんな種類があるかはサービスごとに決まっています。アプリが求めたスコープは同意の画面に並び、本人はそれを見て、許可するかどうかを決めます。サービスの側が、求められたより狭い範囲だけを許すこともあります。
アプリは必要な範囲だけを求め、本人も必要な範囲だけを許す、というのが基本です。この考え方は「最小権限とは」でくわしく説明しています。たとえば、空き時間を見せるだけの予約のツールが「メールを送る」許可まで求めていたら、いったん止まって理由を確かめます。
アクセストークンとリフレッシュトークン
OAuth でアプリが受け取るトークンには、2 つの種類があります。
| アクセストークン | リフレッシュトークン | |
|---|---|---|
| 何に使うか | API を呼ぶたびに付けて、データを使う | 期限が切れたときに、新しいアクセストークンをもらう |
| どこへ送るか | リソースサーバー(API) | 認可サーバーだけ |
| 期限 | 短めにすることが多い | 長めのことが多い(サービスによる) |
リフレッシュトークンがあると、アクセストークンの期限が切れるたびに本人へ許可を求め直さなくても、アプリが動き続けられます。出すかどうかはサービスが決めます。長く使えるぶん、アプリはこれをとくに大切にしまっておく必要があります。
OAuth と OpenID Connect はどう違うのか
OAuth の決まりそのものは、データを使う許可を渡す(認可)ためのもので、「この人は誰か」を確かめて伝える(認証)方法までは決めていません。アクセストークンは「この範囲のデータを使ってよい」という合鍵で、持っている人が誰かを示すものではないからです。
そこで、OAuth 2.0 の上に「誰がログインしたか」を伝える層を足したのが、OpenID Connect(オープンアイディー・コネクト)です。OpenID Connect では、アプリに「ID トークン」が渡されます。ID トークンには、どのサービスが、どのアプリのために、いつ、誰を確かめたかが書かれ、書き換えられていないかを確かめられる署名が付いています。
| OAuth 2.0 | OpenID Connect | |
|---|---|---|
| 目的 | データを使う許可を渡す(認可) | ログインした人を伝える(認証) |
| アプリが受け取るもの | アクセストークン | ID トークン(とアクセストークン) |
| 例 | 予約のツールがカレンダーを読む | 「Google でログイン」 |
Google は、ログインに使う OAuth 2.0 の仕組みが OpenID Connect に沿っていると説明しています。「Appleでサインイン」も、OpenID Connect と同じ形の ID トークンをアプリに返します。GitHub のアカウントでのログインは、OAuth で受け取ったアクセストークンで、本人のプロフィールを読む形です。
許可する前と取り消すときに何を確かめるのか
許可する前は、次の 3 つを確かめます。
- ログインの画面のアドレスが、そのサービスのもの(Google なら accounts.google.com など)かを見ます。メールやメッセージのリンクから開いた画面では、とくに気を付けます。偽のログインの画面は、フィッシングでよく使われる手口です。
- 同意の画面で、アプリの名前と、求められている範囲を読みます。本物のサービスの画面でも、悪意のあるアプリが許可を求めてくることがあります。Microsoft はこれを「同意フィッシング」と呼び、アプリの名前やドメインがもっともらしくても、それだけで信用しないよう勧めています。
- 目的に合わない範囲や、心当たりのないアプリなら、許可せずに閉じます。
使わなくなったアプリの許可は、サービスの設定から取り消せます。
- Google: Google アカウントの、ほかのデベロッパーのアプリとのリンクを管理するページ(Google の説明)
- Apple: iPhone の「設定」で自分の名前を押し、「Appleでサインイン」からアプリを選んで削除する(Apple の説明)
- GitHub: 「Settings」の「Applications」にある、認可された OAuth アプリの一覧から取り消す(GitHub の説明)
取り消すと、アプリは新しいトークンをもらえなくなります。ただし、サービスの作りによっては、取り消す前に渡ったアクセストークンが、期限が来るまで使えることがあります。また、取り消しても、アプリの側にあるアカウントやデータが自動で消えるわけではありません。消したいときは、アプリで退会や削除の手続きをします。
まとめ
- OAuth は、パスワードを渡さずに、範囲と期限の決まったトークンでアプリに許可を渡す仕組みです
- 基本は認可コードの流れで、いまは PKCE を組み合わせることが勧められています
- スコープは許可の範囲で、本人が同意の画面で確かめて決めます
- 「Google でログイン」は、OAuth 2.0 の上に足した OpenID Connect で、ログインした人を伝えています
- 使わない許可は、サービスの設定から取り消せます
mukumo では Google などのアカウントでログインできますか
mukumo(ムクモ)には、パスワードがありません。ログインの画面は登録も兼ねていて、Google・Apple・GitHub のアカウントでログインできます。ほかに、メールに届くコードとパスキーも選べ、前回使った方法には「最終使用」と出ます。
認証アプリのコード(二段階認証)を設定すると、Google・Apple・GitHub でログインしたあとにもコードを聞かれます。設定するかどうかは任意で、設定の「アカウント」の「認証アプリ」から行います。
よくある質問
OAuth で許可したアプリに、パスワードは知られますか
知られません。パスワードを入れるのはサービス自身のログインの画面だけで、アプリが受け取るのはトークンです。ただし、偽のログインの画面に入れてしまうと盗まれるので、画面のアドレスを確かめます。
「Google でログイン」を使うと、相手のアプリに何が伝わりますか
Google の説明では、ログインに使うときに伝わるのは、Google アカウントの名前・メールアドレス・プロフィールの写真です。メールや予定表などのデータを使うには、それとは別の許可が必要です。
許可を取り消すと、相手のアプリのアカウントやデータは消えますか
自動では消えません。取り消しで止まるのは、そのサービスのデータを使う許可や、そのサービスでのログインです。アプリにあるアカウントやデータを消したいときは、アプリの側で退会や削除の手続きをします。
API キーと OAuth のトークンは何が違いますか
API キーは、自分のアカウントでプログラムを動かすために、自分で作って管理する鍵です。OAuth のトークンは、データの持ち主が同意の画面で許可したときに発行され、範囲と期限が結び付いています。