テクの雑学

第147回 oauthとは?その仕組みを徹底解説〜便利と危険は裏返し〜

過去の記事を整理・一部リライトして再掲載したものです。 古い技術情報や、 現在、TDKで扱っていない製品情報なども含まれています。

インターネット上で簡単に写真が共有できるオンラインアルバムサービス、YouTubeなどの動画共有サービス、mixiやFacebookなどのSNS(ソーシャル・ネットワーク・サービス)、Twitter、ブログなど、ユーザー登録をしてさまざまな情報を発信できるWebサービスが増えてきました。これら複数のサービスを利用する時に、わざわざIDとパスワードを入れ直したりせずに、シームレスに利用できるようにする仕組みが「OAuth」です。

複数のアプリケーションを連動させる便利な仕組み

OAuthとは、複数のWebサービスを連携して動作させるために使われる仕組みです。通常、Webサービスを利用するためは、個別にユーザーIDとパスワードを入力してユーザーを認証する必要がありますが、OAuthを利用することで、IDやパスワードを入力することなく、アプリケーション間の連動ができるのです。たとえば、あなたがオンラインアルバムサービスに写真を投稿すると、同時にあなたのユーザーアカウントでTwitterに「アルバムサービスに写真を投稿しました」というメッセージといっしょに、写真を投稿したページのURLをツイート(つぶやき)するような仕組みです。
 

 アプリケーション間の連動には、「API」(Application Program Interface)と呼ばれる命令や関数の集合を利用します。操作する側のWebサービスが、操作される側のWebサービスが用意しているAPIを呼び出し、ユーザーリソース(サービス内に保存されているデータ)へのアクセスや機能の利用を連動して行うのです。

■ OpenIDとは何が違うの?

 以前紹介した「OpenID」(テクの雑学 第96回 ひとつのIDでさまざまなサービスを  -OpenID-)は、ひとつのサービスで利用している認証用のユーザーIDとパスワードを、複数のWebサービスで共通に使用するというものでした。この仕組みは、Webサービスの増加に伴い、マッシュアップ(複数のWebサービスを連動させて新しいサービスを作ること)が行われるようになってきたことで、ユーザーが複数のサービスに別々にユーザー登録をするわずらわしさを防ぐための仕組みです。

 OpenIDでは、連携して機能する複数のWebサービスのユーザーが同一人物であることはわかりますが、Webサービス間でどのユーザーリソースに対してアクセスできるか、また、どのような操作ができるかという認可を行うものではありません。したがって、共通のユーザーIDを使ってログインしても、操作はあくまでもユーザーが別々に行うことが原則となります。

 一方OAuthでは、認証を与えたサービスの保持しているユーザーリソースを、認証を与えられたサービスが利用することができます。どのような利用が可能か(参照だけか、書き換えが可能かなど)についても、OAuthの認証の中で明確に記述されています。
 

■ OAuthの動作の仕組み

 OAuthは、ユーザーの情報とリソースを保持しており、認証を行うアプリケーション(サービスプロバイダー)、認証を受けてサービスプロバイダーが持つユーザーリソースを操作するアプリケーション(コンシューマー)、リソースの持ち主であるユーザー、の3者がデータをやりとりして実現しています。
 先ほどの例でいえば、「サービスプロバイダー」がTwitter、「コンシューマー」がオンラインアルバムアプリケーション、「ユーザー」があなたになります。



 さて、OAuth認証では、実際にはどのようなデータがやりとりされているのかを、順を追って見ていきましょう。

1. サービスプロバイダーが、コンシューマーにOAuth利用許可を与える
 この操作は、ユーザーがリクエストを行う前に、コンシューマーとサービスプロバイダーの間で1回だけ行えばよい操作です。具体的には、コンシューマーがサービスプロバイダーに登録を行い、「登録証明書」にあたるConsumer KeyとConsumer Secretという値を取得します。つまり、「ユーザーに対してサービスを提供する前に、Webサービス間での登録処理が必要」ということです。登録処理そのものは、サービス提供者があらかじめ行っておくケースと、ユーザーが初回利用時に自分で行うケースがあります。


2. ユーザーの同意を確認する
 実際にユーザーがコンシューマーを通してサービスプロバイダーのサービスを利用したい時には、「コンシューマーからサービスプロバイダーにアクセスを許可する」という同意を確認します。「利用許可証」にあたる「リクエストトークン」をサービスプロバイダーが発行し、ユーザーが承認します。

 具体的には、コンシューマーのWebページから、サービスプロバイダーのWebページへとリダイレクト(自動的に移動)され、「許可する(Allow)」か「拒否する(Deny)」のいずれかを選ぶことになります。

 そのページには、ここで「許可」を選んだときに、「何を許可するか」が明記されています。たとえば、データを更新する、消去する、といった操作が書かれていますので、きちんと確認しなくてはいけません。「許可」を選ぶと、コンシューマーによるサービスプロバイダーのユーザーリソースへのアクセスに、ユーザーが同意したことになります。


3.API経由の許可を与える
 いったんユーザーが同意した後は、必要に応じて、コンシューマーはサービスプロバイダーに対して、API経由でユーザーリソースの操作の許可を申請します。コンシューマーの送信した登録証明書と利用許可証が正しければ、サービスプロバイダーは、APIを利用するためのカギにあたる「アクセストークン」と、そのカギの利用者証明にあたる「トークンシークレット」をコンシューマーに対して渡します。サービスプロバイダーは、カギと利用者証明を使ってAPIにアクセスし、サービスプロバイダーのデータを操作します。

 

■ 便利な反面、悪用されると怖いことになる

 最初の例では、コンシューマーアプリケーション(オンラインアルバムサービス)に写真を投稿すると、アプリケーションが自動的にサービスプロバイダー(Twitter)に投稿するというものでした。
 ですが、この仕組みを見れば分かる通り、いったん「登録証明書」と「利用許可証」を持ったコンシューマーは、ユーザーの操作の有無には関係なく、必要に応じてカギの申請を行うことができます。つまり、コンシューマーになるアプリケーションが、ユーザーの意図とは異なる操作をサービスプロバイダーに対して行う可能性もあるのです。

 実際に、この仕組みを利用して、一見ゲームや画像共有サービスのようなふりをしてOAuth認証を受けることで、勝手にそのゲームへの勧誘のメッセージを送信したり、マルウェア(コンピュータウィルスや、コンピュータに入力したIDやパスワードをのぞき見るようなプログラム)をダウンロードするページへのリンクをTwitterでつぶやいたり、SNSサービスの掲示板に書き込むような悪質なサービスも出てきています。

 あなたの知人があなたの名前で発信されたメッセージを信じて、被害にあってしまった場合、あなた自身がOAuthで「許可」を選択している以上、「悪意のあるWebサービスが勝手にやったことだ」という言い訳は通用しません。知らないうちに加害者にならないためには、以下のような点に注意する必要があります。

むやみにOAuthを「許可」しない
 Webサービスを利用するとき、OAuthを求められたら、むやみに「許可」してはいけません。どのサービスが、どのサービスに対して許可を求めているのか、許可した場合、どのようなリソースをどのように操作するか、きちんと読んで理解してから許可しましょう。読んでもわからない場合は、どんなに便利なサービスでも、「拒否」しなくてはいけません。

TwitterやSNSなどへの自分の発言は定期的に確認する
 悪意のあるWebサービスがOAuthを求める目的のほとんどは、あなたの名前であなたの知人あてにメッセージを送信させることで、信用させてマルウェアをダウンロードさせるページへ誘導することです。Twitterやmixi、FacebookなどのSNS、メールの送信記録など、あなたの名前で発信されたメッセージの中に、心当たりのないものがないか、定期的に確認しましょう。

 万一、自分に覚えがないメッセージが発信された形跡がある場合は、そのサービスが発行しているOAuthを確認して、認証した覚えがないアカウントがないかどうかを確認します。また、必要に応じて、Webサービスの運営者に対し、アカウント停止処置の申請や、パスワードの変更を行います。

 なお、パスワードの変更については、くれぐれも慎重に行ってください。万一、自分のパソコンにすでにスパイウェア(キーボード入力などを監視するソフトウェア)を送り込まれていた場合、パスワード変更の処置を盗み見られて、新しいパスワードを奪われてしまう可能性があります。パスワード変更前に、できればクリーンインストール(パソコンのディスクを初期化して、再度OSのインストールからやり直すこと)をすることが望ましいですが、難しければ最低限ウィルス対策ソフトですべてのディスクをチェックしましょう。

 OAuthは便利な仕組みですが、利用には危険もあることを理解して、慎重に利用しましょう。


著者プロフィール:板垣朝子(イタガキアサコ)
1966年大阪府出身。京都大学理学部卒業。独立系SIベンダーに6年間勤務の後、フリーランス。インターネットを中心としたIT系を専門分野として、執筆・Webプロデュース・コンサルティングなどを手がける
著書/共著書
「WindowsとMacintoshを一緒に使う本」 「HTMLレイアウトスタイル辞典」(ともに秀和システム)
「誰でも成功するインターネット導入法—今から始める企業のためのITソリューション20事例 」(リックテレコム)など

PAGE TOP