技業LOG
OAuthの概要
近年、私たちの周りには様々なWebサービスが普及しており、LINEやTwitterなどを筆頭に、みなさんも日々利用しているのではないでしょうか。その中にはアカウントを登録し、いろいろな情報・設定を追加していくものも多くあります。それだけ個人のためにカスタマイズできるものなので、異なるサービスのアカウントを連携させて、よりよい価値を提供しようという考えが広がってきました。
OAuthとは、そのようなサービス間の連携を安全に実現するために考案されたフローです。たとえば、InstagramからTwitterにも同時に写真を投稿したり、あるカレンダーアプリからGoogleカレンダーの予定を参照したりといったものです。
OAuthのフロー
では、実際にOAuthでの認可のイメージをざっくりと掴んでいきましょう。
今回はOAuth 2.0の仕様を解説していきます。OAuth 2.0の手順にもImplicit GrantやClient Credentials Grantなどの種類がありますが、ここではAuthorization Code Grantとよばれるものを取り上げます。後ほど図解しますが、まずは文章だけの流れからイメージしてみてください。
- ① 連携元のサービスAから連携先のサービスBにアクセスする
- ② ユーザーはサービスBにログインする
- ③ ユーザーはサービスB上で、Aからのアクセスや操作などを許可する
- ④ サービスBからAに対して、アクセストークンが発行される
- ⑤ 以後、サービスAからBへの連携はそのトークンを利用しておこなう
まず意識すべきなのがゴールである⑤の部分です。トークンとはいわば、連携先のサービスにアクセスするための許可証のようなものです。アクセスの度にID/PASSを入力するのでは非常に手間がかかってしまうので、ユーザー認証をおこなうのは最初だけにしておいて、以後はトークンを許可証としてアクセスする、というイメージです。最終的には、このトークンを利用した連携が目的となっているので、そのための準備として「正しいユーザーでログインする」という手順と、「必要な処理を許可する」という操作が必要となり、①～③ではそれがおこなわれているのです。上記のフローは簡略化したものではありますが、ここで登場した処理が要点となります。
では、改めて図を用いて、もう少し厳密に具体例を見ていきましょう。あるアプリケーションとTwitterを連携させる例を下の図に示します。少し順序が入り組んでいるので注意してください。
(1)から順に見ていきましょう。まず、「(1) Twitterとの連携を要求」とありますが、一連の連携のトリガーとなるものは何でしょうか。多くの場合、アプリケーション側で「Twitterと連携する」といったリンクや、それを促すダイアログなどがあり、そういったものをきっかけにOAuthの処理が始まります。
次に、「(2) ユーザーをTwitterにアクセス（リダイレクト）させる」とあります。連携の要求を受け取ったアプリは、OAuthでの認証・認可用に開設されたTwitterのページにユーザーを誘導します。
続いて「(3) ユーザー認証」ですが、これは先ほどの説明と相違ありません。連携対象となるTwitterのアカウントでログインします。
次は「(4) アプリがTwitterと連携することを許可」の処理です。
連携元となるアプリにどのような権限を与えるのか、何か規約・注意事項があるのかなどはよく確認しておくとよいでしょう。
なお、下にTwitterでの連携画面の例を示します。ここではQiitaからTwitterへのリクエストを例としていますが、このように認証と認可がひとつの画面にまとまっていたり、何を許可するかはあらかじめ規定されていたりといったケースも多くあります。
認可が完了すると、「(5) ユーザーに認可コードを付与」のステップとなります。
認可コードとは、該当するユーザーが認可をおこなったことを証明するもので、ユーザーに直接送られます。
実は、ここからの処理はユーザーに見えるものではなく、システム間のみでおこなわれます。つまり、ユーザーの仕事は先ほどの認証と認可までであり、それさえ済めば自動的に連携ができる状態まで進むことになります。
続いては「(6) アプリに認可コードを譲渡」です。
前のステップで、認可コードはTwitterからユーザーに送られました。その後のシステム間の処理を進めるためには、それをアプリに渡す必要があります。「それなら最初からアプリに渡せばいいじゃないか」と思うかもしれませんが、あくまで認証・認可をおこなったのはユーザー自身なので、その証明である認可コードはまずユーザーに送られ、その上でアプリに渡されるべきですね。
そして、「(7) Twitterに認可コードを送信」のステップで認可コードがTwitterに送られます。
コードを受け取ったTwitterは、すでにユーザーに払い出したものと一致するかを確認します。もしここで一致しなければ、そのリクエストを不正とみなします。
いよいよゴールに近づいてきました。「(8) アクセストークンを発行」の処理で、アプリがTwitterと連携するために必要なトークンが付与されます。先ほど説明したように、トークンはTwitterと連携するための許可証となるものです。
これらの手順が完了すると、ついに目的であった「(9) 連携」が可能となります。
ここから先、Twitterに対してこのトークンとともに連携のリクエストが送られれば、Twitterは「あのアプリからあのユーザーアカウントとの連携だな」と判別することができます。トークンが適切であり、与えられた「権限の範囲」での操作であれば、正常に連携の処理がおこなわれます。もしトークンが不正な値だった場合、また不正な操作を実行しようとした場合、リクエストは否認されます。
以上がOAuthの連携フローです。なお、OAuthではいくつかの用語が定義されており、それを図の赤い文字で示しています。
上記の例ではユーザーはResource Ownerとよばれます。これはアカウント情報の所持者を指すもので、このResource Ownerが権限の操作を実行します。アプリはClientとよばれます。
クライアントというとエンドユーザーをイメージしがちですが、「認可をもらうクライアント」という意味なので、アプリが当てはまりますね。TwitterはResource Server兼Authorization Serverとなります。
Resource Serverはユーザー情報の操作を担う部分で、Twitterでたとえるならばユーザーのツイートを取ってくるAPIなどですね。Authorization Serverは認証をおこない、認可コードとアクセストークンを管理する部分です。図では簡略化のためにこれらをひとまとめに表記していますが、機能群としてこれらは分けて考えられます。
OAuthと類似した技術
OAuthと類似した技術として、xAuth、OpenID Authentication、OpenID Connectがあります。これらとOAuthとの違いを順に見ていきましょう。
xAuth
xAuthもOAuthと同じく、異なるサービスを連携させるための仕組みです。
OAuthとの大きな違いは、サードパーティのアプリケーションにユーザーアカウントのID/PASSを渡してしまうという点です。上の図の例でいうと、アプリにTwitterアカウントのID/PASSを教え、アプリはそれを用いて好きなときにTwitterにアクセスします。
OAuthと比較して、ユーザーの秘匿情報を渡してしまうことになるため単純に危険性が高く、あまり利用されていません。
OpenID Authentication
OAuthとの最も大きな違いは、認可のプロトコルであるか認証のプロトコルであるかという点です。
OAuthは認可を目的とした規格である一方、OpenID Authenticationは認証を目的として策定された規格であるということです。
「認可（Authorization）」とは何かを認め、権限・許可を与えることです。
先ほどのOAuthの説明で「許可する」や「権限の範囲で」といった言葉が登場したのはそのためであり、それによってサービス間の連携が可能となります。
続いて後者ですが、ここでの「認証（Authentication）」とはユーザー認証のことです。
あるユーザーが正当な利用者であることを証明する、ということですね。多くの場合、これにはIDとパスワードの入力が求められますが、サービスが増えれば増えるほどこのID/PASSの管理というのは煩雑になってきます。
OpenIDは、こういった悩みの解決策となるもので、シングルサインオン（単一の認証で複数のサービスを利用できる機能）のプロトコルです。イメージとしては、TwitterのアカウントでGitHubにもQiitaにもログインできる、といったようなものでしょうか。
OpenID AuthenticationはOAuthよりも早く登場し、2006年に標準化されました※1。当時からすでに、種々のサービスに散在したID/PASSの管理の煩雑さは悩みとされていたため、OpenIDの利用は広がっていきました。そんななか、冒頭で示したように「認証だけでなく機能まで連携させたい」という思想が生まれました。
ただ、OpenID Authenticationはあくまで認証の部分しか実装しておらず、認可はサポートしていませんでした。そこで2007年にOAuth 1.0が考案・公開され、2012年には脆弱性の対策を施したOAuth 2.0に改定されました※2。
OpenID Connect
当初、前の項目で説明したOpenID Authenticationはシングルサインオンを実現するために考案されましたが、OAuth 2.0のフローを利用することによって機能拡張がおこなわれています。それがOpenID Connect 1.0であり、2014年に最終盤としてリリースされました※3。
どのように拡張されたのかというと、まずはOpenIDとOAuthで別々に実現されていたシングルサインオンと認可を統合し、どちらも提供できるようになりました。加えて、連携されたアカウントのユーザー名やメールアドレスといった基本的な情報をやりとりすることが可能となりました。
最後に、仕様や背景についていくつか留意してほしいことがあります。
まずは、OAuthやOpenID Connectはサードパーティであるアプリケーションに、自身のアカウントへのアクセス権を渡してしまうものなので、連携をおこなうのはそのアプリケーションが信頼できる場合に限定するべきでしょう。
また、OAuthはあくまで認可のために作られたものだと今まで説明してきましたが、OAuthを認証のために利用しているケースも見受けられます。それがOAuthの思想に合うかどうかはともかく、事実としてそういったケースも存在します。
以上がOAuthおよびそれを取り巻く環境についての概略です。今や、Webサービスは互いに連携することが前提になりつつあるように感じます。今後、こういったAPIの技術はさらに発展し、普及していくのではないでしょうか。
- ※1
- ※2
- ※3