SIOS Tech. Lab | エンジニアのタメになるOSS・クラウド・認証の技術トピックス 
こんにちは、サイオステクノロジー技術部 武井です。今回は、OAuthをなるべくわかりやすく書きたいと思います。私自身が非常に理解に苦しんだので、誰かのお役に立てれば幸いかなと・・・。
OAuthとは？
OAuthの仕組みは非常に複雑です。私も最初は何がなんだかわかりませんでした。平たく言ってしまえば、「あるサーバーの認可を他のサーバーで行う」ということなのですが、この説明でもさっぱりわけがわかりませんでした。
なので、まず、ここではなるべくわかりやすくOAuthの仕組みを説明させて頂きます。
説明を円滑に行うために、1つのシステムを例にあげます。Twitterにつぶやくと、自動的にそのつぶやきがFacebookにも反映される仕組みです。
※説明の中で出ているFacebookやTwitterのURLは適当です。また、実際にFacebookやTwitterにこのような仕組みがあるかもわかりません。説明をわかりやすくするための例として上げたことをご理解ください。
OAuthのない世界
まず、この仕組を、もしOAuthを使わない場合にどのようになるかを説明します。まずAさんは、TwitterのシステムにFacebookに接続するためのユーザーIDとパスワードを登録します。
AさんがTwitterにつぶやきます。
Twitterは、AさんのつぶやきをFacebookに反映するために、あらかじめTwitterのシステム内に登録されているAさんのユーザーIDとパスワードでFacebookに接続します。
Facebookへの認証が完了すると、AさんのつぶやきをTwitterがFacebookに投稿します。これでTwitterとFacebookの連携は完了です。
しかし、このしくみは、大きな弱点があります。TwitterにはAさんのFacebookのユーザーID・パスワードが登録されています。仮に、もし仮にですが、Twitterを運営している人に悪い人がいて、その人がAさんのFacebookのID・パスワードで勝手にFacebookに接続できてしまいます。投稿の削除や退会ができてしまいます。
OAuthのある世界
これを解決するのがOAuthです。まずTiwtterを運営するシステム管理者は、Facebookに対して、OAuthで接続させてくださいみたいな事前の申請をします。これは、Twitterシステム管理者とFacebookの間で最初の一度だけ行われるやり取りです。そのときに必ず、Facebookに対して行いたい作業(閲覧や投稿)も合わせて申請します。
申請が終わると、Facebookは「クライアントID」「クライアントシークレット」をTwitterシステム管理者に発行します。またTwitterから申請があった作業(投稿や閲覧、以下利用サービスと呼びます)を独自の文字列に変換します。Facebook、Twitterは、そのクライアントID、クライアントシークレット、利用サービスを自身のデータベースに保存します。ここまででTwitterシステム管理者の仕事は終わりです。この作業はOAuth利用時にシステム管理者が最初の一度だけ行えばよい作業です。
ここからは、利用者であるAさんがTiwitter→Facebook連携を行います。まず、Aさんは、Twitterにアクセスして、Tiwitter→Facebook連携の設定画面にアクセスします。
すると、Aさんは、Facebookにリダイレクトされて、Facebookのログイン画面が表示されます。このリダイレクトの際、URLのクエリパラメータにclient_idを付与します。次の工程でこれを使います。
ログインすると、Facebookは、Twitterと連携してもよいかどうかの確認画面を表示します。Facebookは、多分、いろんなサービスとの連携を許可していると思いますが、その多数あるサービスの中から、Twitterとの連携がOKかどうかの画面を表示できたのは、先程リダイレクトの際にクエリパラメータに渡されたクライアントIDから判断しています。
Aさんが先程の画面で「OK」をクリックすると、Twitterにリダイレクトされます。この際、認可コードというものが発行されます。リダイレクトされたときのURLのクエリパラメータにcode=…と言うかたちで、Twitterに渡されます。これは、後にTwitterがFacebookにアクセストークンを要求するための、非常に有効期限の短い通行手形のようなものです。Facebookは認可コード発行と同時に、認可コードを自身のデータベースに保存します。
TwitterはFacebookにアクセストークンを取得しに行きます。その際、先程発行された認可コードを渡します。
認可コードを要求されたFacebookは、自身が発行してデータベースに登録した認可コードとその有効期限を確認し、問題がなければ、Twitterにアクセストークンを返します。アクセストークンを発行したFacebook、アクセストークンを受け取ったTwitterの両方は、ユーザーIDとアクセストークンが紐付いた情報をデータベースに登録します。
Aさんは、Twitterにつぶやきます。
TwitterはAさんのつぶやきを画面に表示します。それと同時に、Facebookにも同様の投稿を行います。この際、Facebookには、投稿の内容と同時に、アクセストークンを渡します。アクセストークンは、Twitterへのログインユーザーをキーにデータベースから取得します。
アクセストークンを受け取ったFacebookは、データベースからアクセストークンを検索して、もし見つかったら、それに紐づくユーザーIDで、Facebookに投稿します。これで、連携完了です。
ところで、ここで、先程の悪い人が再登場したとします。でもアクセストークンには、利用サービスにあるように、投稿と閲覧の権限しかありません。アクセストークンは、FacebookのユーザーIDとパスワード違って、全ての権限を持ちません。当然ながら、アカウントの削除など出来ません。つまり、FacebookのユーザーIDとパスワードをTwitterに渡すのではなく、ごく限られた権限した持たないアクセストークンしか渡さないことにより、セキュリティを保っているわけです。
OAuthは、上記のようなサービス間の連携をする場合、サーバー内に保存されたアカウント情報を悪用する悪い人から、善良なユーザーを守るために作られた仕組みなのです。
最後に
なるべくOAuthの説明をわかりやすくしたつもりですが、いかがでしたでしょうか？次は、このフローに従って実際にOAuthクライアント、OAuthサービスプロバイダーを実装してみようと思います。
Be the first to comment