「Googleカレンダーと連携する」「外部サービスからデータを取り込む」。こうした機能の設定画面や説明で、よく登場するのが「OAuthクライアント」という言葉です。
OAuthという言葉を聞いたことがあっても、「クライアントは何を指すのか」「Client IDとアクセストークンはどう違うのか」が分かりにくいこともあるでしょう。
この記事では、スケジュール管理アプリとGoogleカレンダーの連携を例に、OAuthクライアントの役割と基本的な仕組みを解説します。ここでは、現在広く利用されているOAuth 2.0を扱います。
OAuthクライアントとは？
OAuthクライアントとは、OAuthの仕組みを使って、ほかのサービスへのアクセス権限を取得し、その権限でデータの取得や操作を行うアプリケーションのことです。
例えば、スケジュール管理アプリがGoogleカレンダーの予定を読み取り、アプリ内に表示する機能を提供しているとします。この場合、OAuthクライアントに当たるのは、予定を読み取ろうとするスケジュール管理アプリです。
「クライアント」という名前ですが、ここでは顧客や利用者ではなく、連携先へアクセスを要求するアプリを指します。
登場する役割を整理すると、次のようになります。
| 役割 | Googleカレンダーとの連携例 |
|---|---|
| ユーザー | 自分のカレンダーへのアクセスを許可する人 |
| OAuthクライアント | 予定を読み取りたいスケジュール管理アプリ |
| 認可サーバー | ユーザーの確認や許可を受け付け、トークンを発行するGoogle側の仕組み |
| リソースサーバー | トークンを確認し、予定データを提供するGoogleカレンダーのAPI |
APIとは、アプリやサービスがデータをやり取りするための窓口です。OAuthクライアントは、この窓口を通じて許可されたデータへアクセスします。
OAuthでパスワードを渡さずに連携できる理由
スケジュール管理アプリにGoogleアカウントのIDやパスワードを直接預けると、アプリ側がその情報を管理する必要があります。また、予定の読み取りだけを任せたいのに、必要以上の操作ができてしまうおそれがあります。
OAuthを使ったこの連携では、ユーザーはGoogle側の画面でログインし、スケジュール管理アプリに許可するアクセス範囲を確認します。アプリにはGoogleのパスワードではなく、許可されたアクセスに使う「アクセストークン」が渡されます。
アプリにはパスワードを渡さず、許可した操作の範囲をトークンで管理します。
ここでいう「許可」は、専門用語で「認可」と呼ばれます。「誰であるかを確かめる認証」と、「どのデータにアクセスしてよいかを決める認可」を分けると、理解しやすくなります。
OAuthはアクセス権限を委ねるための仕組みです。ログイン機能で使われることもありますが、ユーザーの本人確認を扱う場合には、OAuth 2.0を土台としたOpenID Connectなどが利用されます。
OAuthによる連携の流れ
代表的な「認可コードフロー」では、連携は次の順番で進みます。
- ユーザーが連携を開始する
スケジュール管理アプリで「Googleカレンダーと連携する」を選びます。 - アプリが必要な権限を要求する
「予定を読み取る」などのアクセス範囲を指定し、Google側の画面へユーザーを案内します。 - ユーザーがGoogle側でアクセスを許可する
必要に応じてログインし、アプリ名と要求されている権限を確認して許可します。 - アプリが認可コードを受け取る
Google側からアプリへ戻る際に、トークンを取得するための一時的なコードが渡されます。 - アプリがコードをアクセストークンに交換する
アプリがGoogle側へ認可コードを送信し、アクセストークンを取得します。 - アプリがトークンを使ってAPIにアクセスする
GoogleカレンダーのAPIへトークンを提示し、許可された範囲で予定を読み取ります。
これは代表的な流れを簡略化したものです。実際の手順やセキュリティ対策は、アプリの種類や連携先サービスによって異なります。
アクセストークンとスコープの役割
アクセストークンは、アプリがAPIにアクセスする際に提示する情報です。連携先サービスは、トークンの有効性や権限を確認して、要求された操作を受け付けるか判断します。
アクセスできる範囲は「スコープ」と呼ばれます。例えばGoogleカレンダーでは、予定を読み取る権限と、予定を読み書きする権限が分かれています。
予定の読み取りだけが許可されたトークンであれば、その権限で予定の追加や削除はできません。アプリが必要な権限を要求し、許可された範囲で連携することが基本です。
また、アクセストークンには有効期限が設定される場合があります。継続的な連携では、新しいアクセストークンを取得するために「リフレッシュトークン」を利用することもあります。
Client IDとClient Secretとは？
OAuthクライアントの設定では、「Client ID」と「Client Secret」という情報も登場します。通常は、アプリの開発者や管理者が連携先サービスにアプリを登録し、必要な情報を取得します。
どちらもアクセストークンとは役割が異なります。
| 情報 | 主な役割 | 押さえておきたい点 |
|---|---|---|
| Client ID | どのアプリがアクセスを要求しているかを識別する | ユーザーのIDではなく、アプリを識別するID。秘密情報ではない |
| Client Secret | 必要な場合に、アプリ自身を認証する | ユーザーのパスワードではなく、アプリ用の秘密情報 |
| Access Token（アクセストークン） | 許可された範囲でAPIにアクセスする | データの取得や操作に使うため、漏えいを防ぐ必要がある |
Client IDはアプリの識別、アクセストークンは許可された操作の実行に使います。Client IDを持っているだけで、ユーザーのカレンダーを読み取れるわけではありません。
Client Secretを使うアプリと使わないアプリ
サーバー側で動くアプリは、Client Secretをサーバー内で管理できます。一方、ブラウザー上で動くアプリやスマートフォンアプリでは、配布するプログラムに埋め込んだ共通の秘密情報を隠し続けることが困難です。
そのため、Client Secretを使用しないOAuthクライアントもあります。「OAuthを使うならClient IDとClient Secretが必ずセットで必要」とは限りません。
Client Secretを使う場合は、公開するソースコードやブラウザーへ配信するコードに含めず、サーバー側で管理します。アクセストークンも、ログや共有資料などへ不用意に載せないことが大切です。
まとめ
OAuthクライアントとは、ほかのサービスへのアクセス権限を取得し、APIを通じてデータの取得や操作を行うアプリケーションです。
Googleカレンダーとの連携であれば、予定を読み取りたいスケジュール管理アプリがOAuthクライアントに当たります。ユーザーはGoogle側でアクセスを許可し、アプリはパスワードの代わりにアクセストークンを使って連携します。
仕組みを理解するうえでは、次の三つを区別すると分かりやすくなります。
- Client ID： どのアプリなのかを識別する
- Client Secret： 必要な場合にアプリ自身を認証する
- アクセストークン： 許可されたAPI操作に使う
普段使っているサービス連携の裏側では、OAuthクライアントが「必要な権限を取得して、許可された範囲でアクセスする」という役割を担っています。連携を設定する際は、アプリ名と許可するアクセス範囲を確認しておきましょう。
ZendeskのAPIトークンを使う連携の見直しについては、APIトークンからOAuthへの移行支援で、対象連携の棚卸しと切替検証の進め方をご案内しています。