はじめに
OAuthについて学んだことを振り返り、自分の言葉で説明できるようにしたいと思い、この記事を書きました。
学んでいるときに混乱したのが、認証と認可の違いです。「Googleでログイン」と「Googleカレンダーと連携する」は、どちらもGoogleの画面が開くことがあります。そこで何を確認しているのか、アプリはそのあと何ができるようになるのかを、カレンダー連携の例で整理しました。
この記事の対象者
- OAuthという言葉を聞いたことがあり、何に使うのか知りたい方
- 認証と認可の違いを、身近な例で理解したい方
- OAuthのやり取りがどこで始まり、どこで終わるのか知りたい方
OAuthとは？？
OAuth（オーオース）は、パスワードを共有せずに、あるサービスのデータにアクセスする権限を別のアプリへ渡す仕組みです。 この記事ではOAuth 2.0を扱います。
たとえば、タスク管理アプリにGoogleカレンダーの予定を表示したいとします。アプリに必要なのは、カレンダーの予定を読む権限です。Googleアカウントのパスワードそのものには、「予定の読み取りだけに使える」という制限を付けられません。
OAuthを使うと、利用者が予定の読み取りを許可したあと、Googleはタスク管理アプリにアクセストークンを発行します。アプリはそれを許可証のように使い、許可された範囲で予定を取得します。このように、自分にできることの一部を別のアプリにも許可することを権限の委譲と呼びます。
OAuthの登場人物
| OAuthでの呼び方 | カレンダー連携での例 | 役割 |
|---|---|---|
| リソースオーナー | カレンダーの利用者 | 自分の予定へのアクセスを許可する |
| クライアント | タスク管理アプリ | 権限を求め、受け取ったトークンを使う |
| 認可サーバー | Googleの認可を担当する仕組み | 利用者の許可を確認し、トークンを発行する |
| リソースサーバー | GoogleカレンダーAPI | トークンを確認し、許可された範囲で予定を返す |
この例では、どちらのサーバーもGoogleが提供しています。タスク管理アプリから見ると、トークンをもらう相手は認可サーバーで、トークンを提示して予定をもらう相手はカレンダーAPIです。
認証と認可は何が違う？
会社のオフィスに入る場面を想像してみてください。受付で入館証を確認し、「この人は社員のAさんだ」と確かめるのが認証です。そのAさんがどの部屋に入れるか、権限を判断するのが認可です。
Webサービスでも、共有ファイルを開く前に「ログインしてください」と表示されたら、まず利用者のアカウントを確認します。ログイン後に「閲覧権限がありません」と表示されたら、アカウントは確認できていますが、そのファイルを開く権限がありません。
カレンダー連携では、Googleが認証する相手は利用者で、予定を読む権限を受け取るのはタスク管理アプリです。利用者はGoogleにログインしたあとで、アプリとの連携を断ることもできます。
Googleカレンダー連携でOAuthの流れを見てみる
タスク管理アプリに予定を表示するまでには、Googleから予定を読むための許可証をもらう段階と、その許可証を使って予定を取得する段階があります。この許可証がアクセストークンです。
今回のOAuthの認可コードフローは、①でアプリがGoogleに読み取り権限を求めた時点で始まり、⑤でアプリがアクセストークンを受け取った時点で終了します。途中の②ではGoogleが利用者を認証します。⑥はトークン取得後の処理で、アプリがカレンダーAPIに予定を取りに行く段階です。
1. アプリがGoogleに読み取り権限を求める
利用者がタスク管理アプリで「Googleカレンダーと連携する」を押すと、アプリはブラウザをGoogleの画面へ移動させます。その際、Googleに「カレンダーの予定を読む権限がほしい」と伝えます。この権限の要求が、認可コードフローの開始地点です。
2. Googleが利用者を確認する（認証）
Googleは、どのアカウントの予定を連携するのかを確認します。まだログインしていなければ、利用者はGoogleの画面でログインします。すでにログインしていれば、そのまま権限の確認画面に進むこともあります。
3. 利用者がアプリに読み取りを許可する（認可）
Googleの画面に、タスク管理アプリが求めている権限が表示されます。利用者は内容を確認し、「このアプリに自分の予定を読ませてよい」と判断したら許可します。
4. アプリが認可コードを受け取る
利用者が許可すると、Googleはブラウザをタスク管理アプリに戻します。このとき、アプリは認可コードを受け取ります。これは、次の手順でアクセストークンに交換するための、一度だけ使える引換券のようなものです。
5. アプリがアクセストークンを受け取る
タスク管理アプリは認可コードをGoogleの認可サーバーに送ります。Googleはコードなどを確認し、アクセストークンを発行します。
アプリがアクセストークンを受け取った時点で、認可コードフローは終了です。 この時点で、アプリは予定を読むための許可証を手に入れています。
6. アプリがトークンを使って予定を取得する（APIアクセス）
タスク管理アプリは、⑤で受け取ったアクセストークンをGoogleカレンダーAPIに提示し、予定を要求します。APIはトークンが有効で、予定を読む権限があることを確認してから予定を返します。アプリは受け取った予定を画面に表示します。
スコープは「どこまでアクセスできるか」
①でアプリが権限を求めるとき、必要なアクセスの範囲をスコープで指定します。予定を一覧に表示するだけなら、読み取りの権限で足ります。予定を作成したり変更したりする機能には、それに対応する権限が必要です。
たとえば、読み取りだけが許可されたアクセストークンで予定を変更しようとすると、カレンダーAPIはその操作を許可しません。こうして、アプリの機能に合わせて渡す権限を絞れます。
アクセストークンの期限が切れたら？
アクセストークンには通常、有効期限があります。期限が切れると、そのトークンでは予定を取得できなくなります。
連携時にリフレッシュトークンも発行されていれば、アプリはそれを認可サーバーに送り、新しいアクセストークンを取得できます。たとえば翌朝に予定を再取得するとき、リフレッシュトークンが有効であれば、利用者がもう一度許可画面を操作せずに済みます。
| アプリが受け取るもの | どこへ渡す？ | 何に使う？ |
|---|---|---|
| 認可コード | 認可サーバー | 最初にアクセストークンと交換する |
| アクセストークン | カレンダーなどのAPI | 許可された範囲でデータにアクセスする |
| リフレッシュトークン | 認可サーバー | 新しいアクセストークンを取得する |
「Googleでログイン」はどう動く？
カレンダー連携でアプリに必要なのは、予定を読む権限です。「Googleでログイン」では、アプリはどのユーザーをログインさせるかを判断します。
GoogleでのログインにはOpenID Connect（OIDC）が使われます。OIDCはOAuth 2.0を土台に、Googleなどで行われた認証の結果をアプリに伝える仕組みを加えたものです。
Googleは認証の結果をIDトークンとして発行します。ログイン先のアプリは、そのトークンがGoogleから自分宛てに発行されたものかなどを確認し、対応するアカウントでログインを成立させます。
| トークン | 誰が確認する？ | 何のために使う？ |
|---|---|---|
| アクセストークン | データを提供するAPI | 予定の読み取りなど、許可された操作を行う |
| IDトークン | ログイン先のアプリ | どのユーザーが認証されたかを確認する |
見た目が似たログインボタンでも、使う仕組みはサービスによって異なります。たとえばGitHubの公式実装例では、アプリがOAuthで取得したアクセストークンを使ってGitHubのAPIに問い合わせ、利用者のアカウントを確認します。
まとめ
カレンダー連携では、Googleがどのアカウントの利用者かを確認するのが認証で、利用者がタスク管理アプリに予定の読み取りを許可するのが認可です。OAuthは、このようにアプリへ必要な範囲のアクセス権限を渡す仕組みです。
「Googleでログイン」では、OpenID Connect（OIDC）を使って、Googleでの認証結果をログイン先のアプリに伝えます。
自分の中では、同じGoogleの画面が開いても、「誰を確認しているのか」「アプリに何を許可しているのか」を分けて考えると、認証と認可の違いを整理しやすくなりました。