ツールをつなぐ

OAuth とは

OAuth(オーオース)は、パスワードを渡さずに、別のサービスにあるデータを使う許可を、範囲と期限を決めてアプリに渡す仕組みです。「Google でログイン」の土台にもなっています。

この記事でわかること

  • OAuth がどんな困りごとを解決する仕組みかを説明できる
  • 認可コードの流れと、スコープ・アクセストークン・リフレッシュトークンの役割がわかる
  • OpenID Connect との違いと、許可を出す前と取り消すときに確かめることを知る
目次
  1. OAuth はどんな困りごとを解決するのか
  2. OAuth に出てくる 4 つの役割
  3. 許可はどんな流れで渡されるのか
  4. なぜコードを一度はさむのか
  5. スコープとトークンとは何か
  6. スコープと同意の画面
  7. アクセストークンとリフレッシュトークン
  8. OAuth と OpenID Connect はどう違うのか
  9. 許可する前と取り消すときに何を確かめるのか
  10. まとめ
  11. mukumo では Google などのアカウントでログインできますか
  12. よくある質問

OAuth(オーオース)は、あるアプリに、別のサービスにあるあなたのデータを使う許可を渡すための決まりです。パスワードを教える代わりに、使える範囲と期限が決まった「トークン」という合鍵をアプリに持たせます。いま広く使われているのは OAuth 2.0 で、インターネットの技術の標準を決める IETF が、RFC 6749 という文書で定めています。

予約のツールと Google カレンダーを連携するときの許可の画面や、「Google でログイン」のボタンの裏で動いているのが OAuth です。しくみを知っておくと、許可の画面で何を確かめればよいか、いらなくなった許可をどこで取り消せばよいかがわかります。

  1. アプリが頼むカレンダーを見せてください
  2. 本人が許可するサービスの画面で範囲を確認
  3. コードが届く使い捨てで、すぐ切れる
  4. トークンに換える範囲と期限の決まった合鍵
  5. API を使う許された範囲のデータだけ
図アプリが許可を頼み、本人がサービスの画面で許可すると、アプリは受け取ったコードをトークンに換えて、許された範囲だけ API を使う流れ

OAuth はどんな困りごとを解決するのか

たとえば、オンライン講座を開いている人が、予約のツールに自分の Google カレンダーを読ませて、空いている時間だけを受講生に見せたいとします。仮に、予約のツールに Google のパスワードを預けるとしたら、次のような問題が起きます。RFC 6749 の冒頭でも、同じ問題が挙げられています。

  • ツールがパスワードを保存し続けるので、ツールから漏れると、アカウントのすべてが危うくなる
  • カレンダーだけでよいのに、メールや写真まで、何でもできてしまう
  • 1 つのツールだけ止めたくても、パスワードを変えるしかなく、ほかのツールも全部止まる

OAuth では、パスワードはサービス自身のログインの画面にだけ入れます。アプリには、パスワードとは別の、範囲と期限が決まった合鍵(アクセストークン)が渡されます。ホテルのカードキーに似ています。カードキーは自分の部屋しか開けられず、泊まる期間が終われば使えなくなり、フロントで止めることもできます。建物全体の鍵を渡すのとは違います。

OAuth に出てくる 4 つの役割

OAuth の決まりは、登場するものを 4 つの役割に分けています。上の例に当てはめると、次のとおりです。

役割 何をするか 例
リソースオーナー データの持ち主で、許可を出す 講座を開いている本人
クライアント 許可を受けて、データを使う 予約のツール
認可サーバー 本人を確かめ、許可を受けてトークンを発行する Google のアカウントの仕組み
リソースサーバー データを預かり、トークンを確かめて応じる Google カレンダーの API

認可サーバーとリソースサーバーは、同じ会社が動かしていることがよくあります。API そのものについては「API とは」で説明しています。

許可はどんな流れで渡されるのか

Web のアプリでいま基本になっているのは、「認可コード」を使う流れです。

  1. 予約のツールで「Google カレンダーと連携」を押すと、ブラウザーが Google のページに移る。このとき、ツールの名前と、求める許可の範囲(スコープ)が一緒に伝わる
  2. 本人が Google のページでログインし、同意の画面で内容を確かめて許可する
  3. Google が、使い捨ての「認可コード」を付けて、ブラウザーをツールへ戻す
  4. ツールが、そのコードを裏側(ツールのサーバーと Google のあいだ)で送り、アクセストークンに換えてもらう
  5. ツールは、アクセストークンを付けてカレンダーの 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 つを確かめます。

  1. ログインの画面のアドレスが、そのサービスのもの(Google なら accounts.google.com など)かを見ます。メールやメッセージのリンクから開いた画面では、とくに気を付けます。偽のログインの画面は、フィッシングでよく使われる手口です。
  2. 同意の画面で、アプリの名前と、求められている範囲を読みます。本物のサービスの画面でも、悪意のあるアプリが許可を求めてくることがあります。Microsoft はこれを「同意フィッシング」と呼び、アプリの名前やドメインがもっともらしくても、それだけで信用しないよう勧めています。
  3. 目的に合わない範囲や、心当たりのないアプリなら、許可せずに閉じます。

使わなくなったアプリの許可は、サービスの設定から取り消せます。

  • 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 のトークンは、データの持ち主が同意の画面で許可したときに発行され、範囲と期限が結び付いています。

まずは、ひとつ任せてみませんか

登録はメールアドレスだけ。フリープランのまま、muku に話しかけるところから始められます。