OAuthとは？『仕組み』などを分かりやすく解説！

この記事では『OAuth』について、

• OAuthとは
• OAuthの身近な例
• OAuthの仕組み
• OAuthのメリットとデメリット

などを図を用いて分かりやすく説明するように心掛けています。ご参考になれば幸いです。

OAuthとは

OAuthは異なるWebサービスにあるリソースへのアクセス権限を与える仕組みです。OAuthにより、アクセス権限を与えることで、Webサービス間で連携することができるようになります。

一例として、あるユーザが「WebサービスA(例：Instagram)」と「WebサービスB(例：Twitter)」のアカウントを持っている場合を考えてみましょう。

通常、各サービスにあるリソース(投稿など)へのアクセスはログインしているアカウントしか利用することができません。Instagramに投稿するためには、InstagramのIDとパスワードを入力し、ログインする必要があります。同様に、Twitterに投稿するためには、TwitterのIDとパスワードを入力し、ログインする必要があります。

ここで、OAuthによって、InstagramにTwitterへのアクセス権限を与えると、Instagramに投稿するだけで、その投稿内容が自動的にTwitterにも投稿されるといったWebサービス間の連携をすることができるようになります。

これは、ユーザの代わりにInstagramがTwitterのリソースを操作をしているということになります。ユーザがInstagramに対して、TwitterのIDとパスワードを渡しているのではなくて、認可(Twitterにアクセスして投稿する権限を与えること)を委譲しているのがポイントです。IDとパスワードを渡していないので、セキュリティ上のリスクを回避することができます。

OAuthの身近な例

下記にOAuthを利用している身近な例を下記に紹介します。

• Instagram、Twitter、Facebookの連携
  • Instagramに投稿すると、自動的にTwitterとFacebookにも同じ内容が同時投稿することができます。この場合、InstagramにTwitterとFacebookのアクセス権限を与えているということになります。
• Twitterの投稿履歴から診断するアプリ
  • Twitterのリソース(投稿や各種情報など)をアプリに渡すと、Twitterを開始した日付や、これまでの平均ツイート数などを調べることができます。この場合、アプリにTwitterのアクセス権限を与えているということになります。
• カレンダーアプリからGoogleカレンダーの予定を参照する
  • Googleカレンダーのリソースをカレンダーアプリに渡すと、カレンダーアプリにもGoogleカレンダーの内容が表示されるようになります。この場合、カレンダーアプリにGoogleカレンダーのアクセス権限を与えているということになります。

OAuthの「ロール(登場人物)」と「仕組み」

次に、OAuthの仕組みについて説明します。OAuthには4つのロール(登場人物)がいますので、そのロール(登場人物)についてまず説明します。

OAuthのロール(登場人物)

OAuthには下記に示す4つのロール (登場人物)がいます。

• リソースサーバー(RS: Resource Server)
• リソースオーナー(RO: Resource Owner)
• クライアント(OAuth Client)
• 認可サーバ(AS: Authorization Server)

次に各ロール(登場人物)について順番に説明します。

リソースサーバー(RS: Resource Server)

その名の通り、保護されたリソースを保持しているサーバです(例: TwitterやFacebookのAPIサーバなど)。リソースには様々な種類があります。例えば、「SNSの投稿内容」や「Googleフォトの写真」などをイメージすると分かりやすいと思います。

このリソースサーバーへのアクセスにはアクセストークンというものが必要になります(アクセストークンについては後ほど説明します)。

リソースオーナー(RO: Resource Owner)

保護されたリソースの所有者です(だいたい人間です)。リソースオーナーはクライアントが保護されたリソースへのアクセスを許可するか否かの権限を持っています。例えば、「クライアント(Instagramなど)」から「リソースサーバー(Twitterなど)」へのアクセスを許可するか否かはリソースオーナーが決めます。

クライアント(OAuth Client)

保護されたリソースを利用するWebサービス・アプリケーションです(例：ユーザが使っているInstagramなど)。リソースオーナー(ユーザ)の認可を得ると、リソースオーナーの代理として、保護されたリソースにアクセスすることができます。

認可サーバ(AS: Authorization Server)

アクセストークンを発光するサーバです(例：TwitterやFacebookの認可サーバ)。リソースオーナーの認可を得ると、アクセストークンをクライアントに対して発光します。リソースサーバーが認可サーバの役割を兼ねている場合もあります。

OAuthの仕組み

これからOAuthの仕組みについて説明します。

OAuthのアクセス権限付与には4つのグラントタイプがあります。例えば、Implicit GrantやClient Credentials Grantなどがありますが、ここではAuthorization Codeと呼ばれるグラントタイプについて説明します。

一例として、クライアントをInstagram、リソースサーバーをTwitterとして、InstagramからTwitterに連携する場合を考えてみましょう。

クライアントにアクセスして認証開始

リソースオーナー(ユーザー)がクライアント(Instagram)の「Instagram→Twitter連携の設定画面」にアクセスします。

OAuthのトリガーはクライアント(Instagram)側で「Twitterと連携する」といったリンクなどをクリックした時です。上の図では、InstagramはFacebookやTwitterなどの様々なWebサービスと連携することができることが分かります。

ここでは、Twitterと連携したいので、Twitterのリンクをクリックします。リンクをクリックすると、OAuthの処理が始まり、クライアント(Instagram)とリソースサーバー(Twitter)が連携するための手続きが開始します。

認可要求・認可リクエスト

リソースオーナー(ユーザー)からリソースサーバー(Twitter)への連携の要求を受けたクライアント(Instagram)は、Twitterの認可サーバの認可エンドポイントにリダイレクトさせます。Twitterの認可サーバにリダイレクトすることによって、画面(ブラウザなど)に表示されている画面がTwitterの認可サーバが提示している画面に切り替わります。

リダイレクトの際、URLのクエリパラメータにクライアントID (client_id)を付与しています。

ログイン画面・連携同意画面の表示

Twitterの認可サーバはログイン画面や連携同意画面をリソースオーナー(ユーザー)に提示します。この認可画面では、Twitterの認可サーバはリソースオーナー(ユーザー)に対して、クライアント(Instagram)が要求しているアクセスを許可してよいかを確認しています。例えば、「このアカウントでツイートを送信および削除する」などがアクセス権限の範囲として記載されています。

Twitterは色々なWebサービス(例えば、InstagramやFacebookなど)とも連携することができますが、ここで、Instagramとの連携を許可してもよいかと確認できたのは、URLのクエリパラメータで渡されたクライアントID(client_id)で判断しているからです。

ログイン・連携同意

リソースオーナー(ユーザー)は必要に応じて、IDやパスワードなどを入力して、ログインします(認証)。この認証は、Twitterの認可サーバが認可処理を進めるために必要な認証であり、クライアント(Instagram)は認証情報そのものはおろか、認証情報がやりとりされていることすら知りません。また、要求されているアクセス権限のスコープ(Instagramに何の権限を与えるか)を確認し、問題なければ許可します。

認可コードを発行

Twitterの認可サーバで認証と認可が正しく行われると、認可コード(リソースサーバーへのアクセスを許可したことを示すコード)を発行し、クライアント(Instagram)のリダイレクトURLにリダイレクトします。そのため、この処理はリソースオーナー(ユーザー)には見えず、システム間で行われます。

クライアント(Instagram)のURLにリダイレクトすることによって、画面(ブラウザなど)に表示されている画面がクライアント(Instagram) が提示している画面に切り替わります。認可コードはURLのクエリパラメーターに「code=…」という形式で設定して、クライアント(Instagram)にリダイレクトしています。

認可コードを提示して、アクセストークンを要求

認可コードを受け取ったクライアント(Instagram)は、Twitterの認可サーバのトークンエンドポイントに対して、認可コードを提示して、リソースサーバー(Twitter)にアクセスするために必要なアクセストークンを要求します。

アクセストークンを発行

Twitterの認可サーバでは、クライアント(Instagram)から送られた認可コードの有効性を検証しています。「Twitterの認可サーバが発行した認可コード」と「クライアント(Instagram)から送られた認可コード」が一定しているか、有効期限は切れていないか等を確認し、問題がなければ、アクセストークンを生成し、クライアント(Instagram)に発行します。

アクセストークンを提示して、リソース要求

例えば、InstagramとTwitterを連携して、Instagramに投稿したらTwitterにも同じ内容が投稿されるようなケースを考えてみましょう。リソースオーナー(ユーザー)が投稿すると、クライアント(Instagram)は投稿内容とアクセストークンをリソースサーバー(Twitter)に渡しています。アクセストークンを受けとったリソースサーバ(Twitter)は、アクセストークンの有効性を検証し、問題がなければ、Twitterにも同じ内容が投稿されます。

クライアントに対してリソース応答

また、リソース提供の要求もすることができます。クライアント(Instagram)は発行されたアクセストークンをリソースサーバー(Twitter)のリソースエンドポイントに渡して、リソース提供の要求を行います。アクセストークンを受けとったリソースサーバー(Twitter)は、アクセストークンの有効性を検証し、問題がなければ、リソースをクライアント(Instagram)に提供します。

リソースオーナーに対してリソース応答

クライアント(Instagram)はリソースオーナー(ユーザー)に対して、リソースを含む画面をレスポンスします。

OAuthで最初に認可コードをクライアントに渡す理由

OAuthで最初に認可コードをクライアントに渡す理由は、アクセストークンが悪意のある第三者に漏れたり盗まれたりすると、悪用されてしまう可能性があるためです。

認可サーバはアクセストークンを直接URLのクエリパラメータに記載してクライアントに渡すことはしません(悪意のある第三者に盗まれてしまう可能性があるから)。そのため、クライアントに対して、URLのクエリパラメーターに「code=…」という形で認可コードを記載して渡します。

認可コードは漏れたり盗まれてたりする可能性があるという前提で設計されています。例えば、認可コードには短時間の有効期限(推奨10分)を設定されています。そのため、認可コードが盗まれたとしても、比較的安全です。また、アクセストークンを得るためには、クライアント ID とクライアントシークレットも必要になります。クライアント ID とクライアントシークレットは認可サーバのデータベースとクライアントのデータベースに保存されているので、リソースオーナーを含む第三者には知ることができない情報です。

このような点から、認可コードが盗まれても、「認可コードは短時間で有効期限が切れる」&「アクセストークンを得るためには、クライアント ID とクライアントシークレットも必要」という点から比較的安全になります。

OAuthのメリットとデメリット

下記にOAuthのメリットとデメリットを示します。

本記事のまとめ

この記事では『OAuth』について、以下の内容を説明しました。

• OAuthとは
• OAuthの身近な例
• OAuthの仕組み
• OAuthのメリットとデメリット

お読み頂きありがとうございました。